Connecting Tamra Capital’s portfolio surfaces to a third-party stack

Licensed in late 2021 by the Saudi Capital Market Authority, Tamra Capital runs Shariah-compliant ETF portfolios for retail investors across the Kingdom — around 240,000 registered users and roughly US$410 million in assets under management at the figures the platform publishes. The data that matters for an integration sits inside that account: the user’s risk-profile result, the allocation across real estate, gold, local equities, global equities and sukuk, the wallet float, and the deposit log that funds it. None of that travels through the SAMA Open Banking account-information feed, because SAMA’s framework is a bank-side rail and Tamra Capital sits under the CMA, not SAMA. The bridge is the user’s own consent. We treat an authorized session against the Tamra app as the spine of the build, with SAMA AIS attached on the funding-bank side when the project also needs the money trail.

What sits behind a Tamra Capital account

The app is a thin face over an investment-management back end. Most of the value for an integrator is in the per-portfolio state, not in any one screen.

How a portfolio pull looks on the wire

The snippet below is illustrative — the exact paths, field names and refresh cadence are confirmed during the build against a consenting session. Two things to call out: the Tamra-side surface is the app’s own customer-facing API (bearer token, device-id binding), not an Open Banking edge, so PAR and mutual TLS are not in play here; the SAMA leg is a separate adapter that runs against the customer’s bank.

# 1. Tamra-side: portfolio detail (authorized session)
GET /api/v1/portfolios/{portfolio_id}
Authorization: Bearer <jwt>
Accept: application/json
X-Device-Id: <client-installation-id>

200 OK
{
  "portfolio_id": "p_...",
  "type": "moderately_aggressive",
  "currency": "SAR",
  "market_value": 12450.40,
  "deposited": 11000.00,
  "return_pct_ytd": 6.7,
  "holdings": [
    {"ticker": "...", "asset_class": "global_equity",  "weight": 0.42},
    {"ticker": "...", "asset_class": "sukuk",          "weight": 0.28},
    {"ticker": "...", "asset_class": "real_estate",    "weight": 0.18},
    {"ticker": "...", "asset_class": "gold",           "weight": 0.12}
  ],
  "fee_track":         {"class": "gen_z", "rate_monthly_sar": 1.00},
  "last_rebalanced_at": "..."
}

# Token refresh fires on the cadence captured during the build.
# A naive client that follows only the expires_in value will drop
# the session early; the app actually pre-emptively refreshes.

# 2. SAMA AIS leg, against the customer's bank (separate consent)
POST /open-banking/par             # PAR-initiated, mTLS at the edge
GET  /open-banking/accounts/{id}/transactions?from=...&to=...
     # filter by counterparty IBAN of the Tamra settlement account
     # to isolate deposits in and withdrawals out

The build we hand over

Each item below is tied to a Tamra surface, not boilerplate:

• OpenAPI 3 specification covering the authorized Tamra-side endpoints — onboarding, portfolio list and detail, wallet balance, transaction list, return series — with fields recorded as observed during the build.
• An auth-flow report: how the mobile login moves through bearer issuance and refresh, where the device-id binding lives, and the silent-expiry points a long-lived sync needs to handle.
• Runnable client source in Python (httpx + pydantic) and Node.js (axios + zod), with the SAMA AIS leg behind a separate adapter so the two consents do not bleed into each other.
• Automated tests against fixtures captured during the build — including the deposit-pending to settled state machine and the post-rebalance holdings diff.
• Interface documentation pinned to actual screen flows, so a future engineer can re-confirm a surface in the app when the front end changes.
• A short compliance memo: data minimization, consent-record retention, NDA cover, and the explicit list of what we do not touch (the underlying Sharia-screening engine, which is internal to Tamra).

Routes from a Tamra account to your stack

Route 1 — Authorized interface integration with user consent

The user signs an authorization to us, we instrument a consenting session against the Tamra Capital app, document the auth and the relevant endpoints, and ship a working client. Only this route brings back the actual portfolio composition, returns and holdings the user sees. Effort runs 1–2 weeks for a first cut. Durability is solid for the life of a major front-end version; the maintenance contract carries a re-validation pass for new Tamra releases. We arrange the test account and the consent scope with the client during onboarding.

Route 2 — SAMA Open Banking AIS for the funding bank

SAMA’s Account Information Services feed sees the customer’s bank-side view of cash moving to and from Tamra Capital, identified by the platform’s settlement IBAN as the counterparty. It does not see what is inside the Tamra portfolio. The framework moved out of the sandbox and into a formal licensing regime on 26 March 2026, and the wire format is the published standard — PAR for consent, mutual TLS at the edge, scoped account selection, and a renewable consent window. We piggy-back on a licensed partner or an authorized aggregator if you do not hold a SAMA license yourselves.

Route 3 — Native export, where present

The app surfaces statements and a transaction log that the user can download. Useful as a one-shot for migrations, account opening or audit, not for live sync. We script the download against a consenting session and parse the document.

In practice the build runs on Route 1 for portfolio data, with Route 2 attached when the project also needs the bank-side money trail, and Route 3 held in reserve for one-shot backfill.

Consent under Saudi Open Banking and the CMA

Tamra Capital is investment management and advisory under the Capital Market Authority — not a deposit-taking bank — so SAMA’s Open Banking framework reaches the customer’s funding bank, not the Tamra portfolio itself. The dependable basis for the Tamra-side leg is the customer’s own written authorization to us, scoped to the named surfaces, time-boxed, revocable in writing and logged with a hash for the consent record. On the SAMA side, since the 26 March 2026 licensing rollout, the framework requires PAR-initiated consent, mutual TLS at the API edge, and a consent flow that meets the published technical standards; the consent itself is bank-issued, scoped to the accounts the customer picks, and expires on a window the customer renews. Data the build collects is held only for the agreed retention window, encrypted at rest, and never resold. An NDA covers the engagement by default.

Engineering details we account for

• One user, more than one portfolio. The risk questionnaire drives portfolio assignment, but a single user can sit on a Gen Z portfolio and a standard one at the same time, or split between a Conservative pot and a Moderately Aggressive pot for different goals. We model the per-user to per-portfolio relationship explicitly so a downstream report can answer “show me everything this customer holds” without double-counting the wallet float.
• Gen Z fee switch. The Gen Z track runs at 1 SAR per month under 25 and switches to the standard 0.4% annual fee once total investments cross the 60,000 SAR threshold (figures per the platform’s own published terms, ex-VAT). The app does the switch silently, and a naive integration will read the change as a fee jump. We mirror the branch in the schema so the change is explainable.
• SAR display, mixed-currency holdings. Everything user-facing is in SAR, but the underlying ETFs are a mix of TASI-listed instruments and global-equity / global-sukuk funds priced in USD. We surface the FX leg explicitly when the integrator’s reporting layer wants positions in USD; otherwise the SAR view passes through untouched.
• Sharia output, not Sharia methodology. The purification ratio and zakat figures are computed by Tamra against the Shariyah Review Bureau’s screen; the output is exposed, the methodology is not. We carry the output through and label its provenance, rather than re-implementing the screen.
• Bank-side reconciliation. Tamra’s wallet records and the customer’s bank statement do not align perfectly — the bank sees a settlement counterparty, the app records the user-facing wallet event. The adapter ties them together on amount, value-date and counterparty IBAN with a tolerant matcher, not a strict equality join.

Where this integration tends to land

• A Saudi neo-bank or super-app building a unified net-worth view: bank balances via SAMA AIS, the Tamra portfolio via the authorized session, the two stitched together at the wallet boundary.
• A wealth-tech dashboard for retail investors holding more than one robo-advisor: Tamra alongside Wahed, Sarwa or Abyan, normalized into a single ETF-position schema.
• A family-office or household aggregator collecting performance across an under-25 Gen Z account and a parent’s Aggressive portfolio without leaking the under-25 fee track into the parent’s view.
• A zakat tool that needs the purification figures on a quarterly basis without holding the underlying methodology.

Interface evidence

Public store screenshots, kept for reference during the build.

Comparable Saudi and MENA robo-advisors

Useful when the same integration is expected to normalize across more than one platform. Names are listed as ecosystem context, not as a ranking.

• Derayah Smart — Saudi robo-advisor under the CMA with Shariah-compliant portfolios; managed-portfolio data sits behind a similarly shaped account.
• Wahed Invest — global halal robo-advisor active in Saudi Arabia; portfolio holdings, performance and zakat figures across a comparable account.
• Sarwa — UAE-based robo-advisor that accepts Saudi investors; mixed Sharia and conventional portfolios.
• Abyan Capital — Riyadh-based Shariah-compliant robo-advisor for retail investors.
• Drahim — Saudi savings and investment app licensed by both SAMA and the CMA.
• Nakla — early Saudi automatic-investing robo-advisor focused on goal-based savings.
• Al Rajhi Capital — bank-affiliated investment app; brokerage and managed-portfolio surfaces.
• Riyad Capital — Riyad Bank’s investment arm; trading and portfolio surfaces.

Questions a Tamra integrator tends to ask

How much of Tamra Capital’s user data is platform-side versus bank-side?

Portfolio composition, the four risk-band allocations, ETF holdings, return series, wallet balance, and the deposit and withdrawal log are platform-side and reachable through an authorized session against the Tamra Capital app. The customer’s funding bank only sees the cash transfers in and out; the holdings themselves sit inside Tamra.

Does Saudi Open Banking already cover investment platforms like Tamra Capital?

No. SAMA’s framework, which moved into formal licensing on 26 March 2026, covers bank account information and payment initiation. Investment-management platforms regulated by the Capital Market Authority are a separate perimeter, so the actual Tamra portfolio is reached through an authorized session, with SAMA AIS attached only to follow the money trail on the funding bank side.

How do you handle the Gen Z account differently in the schema?

We carry an account-class flag and an active-fee-track field. The 1 SAR per month under-25 rate and the switch above the 60,000 SAR threshold (after which the standard 0.4% annual fee applies) are mirrored as explicit branches, so a downstream reconciliation does not read the rate change as an anomaly when it triggers.

What happens when Tamra ships a new app version?

Portfolio detail and wallet endpoints have proven stable across point releases, but field names and the auth-refresh cadence can shift on a major version. The maintenance contract bakes in a re-validation pass: each new app version is sampled, the deltas are diffed against the captured specification, and the client is patched before the integration breaks in your stack.

Sources we worked from

This brief was put together from the Capital Market Authority’s own licensing news for Tamra Capital, SAMA’s Open Banking Framework page, a recent legal note covering the March 2026 move to a SAMA licensing regime, and Tamra Capital’s Play Store listing. Figures attributed to the platform — registered users, AUM, the Gen Z fee bands and the licence number — are quoted as the platform or the regulator publishes them and are labelled in the body. Reviewed 29 May 2026 by the OpenBanking Studio integration desk.

• CMA — news item on the licensing of Tamra Capital Company
• SAMA — issuance of the Open Banking Framework
• Clyde & Co — SAMA commences licensing of Open Banking firms (March 2026)
• Tamra Capital: Save & Invest — Google Play listing

Source delivery starts at $300 — paid only after the build runs to your satisfaction — and ships on a 1–2 week cycle; on the other side, call our hosted endpoints and pay per call, with no upfront fee. The brief we ask for is short: the Tamra Capital surfaces you need and what your stack does with them. Reach the desk at /contact.html.