Connecting to a Fasset multi-asset account

One Fasset login sits in front of a USD cash account, a stablecoin and crypto wallet, a brokerage holding tokenized stocks, gold and bonds, a Visa-rail spending card, and a yield product — all settling over the company's own stablecoin rails. Coverage is broad: press around its May 2026 funding round describes roughly two million customers across about 125 countries and tens of billions in annualized settlement volume. For anyone building a money app, a tax tool, a treasury dashboard or a portfolio tracker, that is a lot of distinct financial records behind a single account. The work here is reaching them cleanly and with the account holder's consent.

The bottom line: this is a consolidated account, so the value is in reading every asset class through one consented session and reconciling them into a single normalized feed. We would run the integration as authorized protocol analysis of the app's own traffic, anchored to the account holder's consent, with a native statement export as a backup path for the cash and card side.

What one account holds

These are the surfaces a Fasset account actually exposes once you are signed in, named the way the app and its help centre name them.

Reading a balance

A consolidated holdings read is the workhorse call. The shape below is illustrative — exact field names and the auth handshake are confirmed during the build against a consenting account — but it reflects how a multi-asset position list behaves: a bearer session, an account scope, and a list mixing fiat, crypto and tokenized securities.

GET /v1/portfolio/holdings?account=ACC_7Q...&include=fiat,crypto,equity
Authorization: Bearer <session_token>        # rotated; refresh on 401
Accept: application/json

200 OK
{
  "account": "ACC_7Q...",
  "base_ccy": "USD",
  "holdings": [
    { "asset": "USD",   "class": "cash",     "balance": "1840.55" },
    { "asset": "USDC",  "class": "stable",   "balance": "5200.00", "chain": "polygon" },
    { "asset": "BTC",   "class": "crypto",   "qty": "0.0412", "value_usd": "..." },
    { "asset": "PAXG",  "class": "metal",    "qty": "0.85",   "value_usd": "..." },
    { "asset": "AAPL.x","class": "equity",   "qty": "1.20",   "cost_basis": "..." }
  ],
  "earn": { "apy": "10.0", "accrued_usd": "12.40" }
}

# Edge cases we handle in the generated client:
#  - 401 -> silent token refresh, single retry, then surface auth error
#  - tokenized-equity rows carry fractional qty; round only at display
#  - Earn accrual is cumulative -> diff against last poll, never re-add

Deliverables

You hand us the app name and the records you care about; what comes back is runnable, not a slide deck. For Fasset that means:

• An OpenAPI/Swagger specification covering the holdings, transfers, card, Earn and P2P surfaces you select.
• A protocol and auth-flow report — the session-token issue and refresh chain, request signing if present, and how the app scopes a read to one account.
• Runnable source for the key endpoints in Python or Node.js, with the multi-asset normalization already wired in.
• Automated tests, including the 401-refresh path and the fractional-equity and cumulative-Earn edge cases above.
• Interface documentation plus data-retention and consent-logging guidance fit for a VARA-regulated source.

Authorized routes

Three routes genuinely apply to Fasset. Each is set up with you during onboarding — access and credentials are arranged as part of the project.

Authorized interface integration / protocol analysis

We map the app's own client-to-server traffic under the account holder's authorization and rebuild the calls as a documented client. This reaches the widest surface — holdings, card, Earn, P2P — because it reads exactly what the app reads. Effort is moderate; durability is good as long as we keep a re-validation pass for front-end changes.

User-consented credential access

For a single consenting user, the integration runs inside their authenticated session. This is the quickest path to a working read of one account's data and the natural fit for a personal portfolio or tax use case.

Native export fallback

Where the app offers a statement or activity export for the USD account and card, we parse it as a backstop. It is narrower and less timely than the live read, but it is durable and useful for reconciliation. The route we would actually lead with is the authorized interface integration: it is the only one that sees every asset class in the account at once, and the consented-session and export paths slot in beneath it for single-user and reconciliation needs.

What we plan around

Two things about Fasset specifically shape how we build, and we account for both rather than passing them to you as conditions.

• Mixed asset classes under one ledger. A single account holds cash, stablecoins, on-chain crypto, tokenized metals and tokenized equities, each with different precision and settlement behaviour. We design the normalization so fractional equity quantities and 18-decimal token balances reconcile without rounding drift, and so chain-settled assets are tagged with their network.
• Regional and Shariah-driven product variation. Availability of the card, Earn, specific assets and P2P differs by country and eligibility, and the investment set is filtered to Shariah-certified products. We scope the integration per market so a feature absent in one region does not read as missing data, and we map eligibility flags rather than assuming a fixed product set.

Access to a sandbox or a consenting account is arranged with you during onboarding; the build then runs against it. We keep a maintenance re-check for when the app's front end shifts, so the client keeps returning the same normalized shape.

Consent and VARA

Fasset FZE operates under a Virtual Asset Service Provider licence from Dubai's Virtual Assets Regulatory Authority (per the VARA public register), and the group's footprint runs across Indonesia, Pakistan, Bangladesh, Malaysia and Turkey. There is no single consumer open-banking mandate that spans those markets for a crypto-and-fiat account, so the dependable basis for the integration is the account holder's own authorization — not a presumed data-sharing scheme. We capture and log that consent, scope it to the specific records the integration uses, honour revocation, and keep the data set minimized. Where the engagement touches an institution's own systems we work under NDA, and consent records are retained so an access can be shown to have been authorized. UAE personal-data handling under the PDPL frames how that data is stored and transferred.

Shared schema

Mixed asset classes collapse into a small set of records so a downstream system sees one vocabulary, not five.

Holding   { account_id, asset, asset_class, qty?, balance?, value_usd, chain?, as_of }
Movement  { account_id, type: deposit|withdrawal|trade|card_auth|p2p,
            asset, amount, counterparty?, status, ts }
Yield     { account_id, product: "earn", apy, accrued_usd, period_start, period_end }

Screens we worked from

Store screenshots used while mapping the account surfaces. Select to enlarge.

Same money stack

Apps an integrator often sees alongside Fasset when building a unified view of someone's crypto, halal-investing and emerging-market banking footprint. Named for ecosystem context only.

• Wahed — Shariah-compliant robo-investing across stocks, sukuk and gold; holds managed-portfolio positions and contribution history.
• Zoya — Shariah screening and tracking for stocks and ETFs; holds watchlists and compliance status rather than custody balances.
• HAQQ Network — Islamic blockchain ecosystem; on-chain wallet balances and staking records that complement a custodial view.
• MRHB — Shariah-compliant DeFi wallet; non-custodial holdings and staking positions across its products.
• Pintu — Indonesian crypto exchange; per-user balances, trade history and rupiah on/off-ramp records.
• Bank Jago — Indonesian digital bank; account balances, pockets and BI-Fast transfer history.
• SeaBank — Indonesian digital bank; savings balances and transaction records.
• blu by BCA Digital — Indonesian digital bank; account and savings-goal data, transfer history.

Integrator questions

Can a Fasset account's crypto, stock and USD balances be pulled into one feed?

Yes. Fasset keeps cash (the USD account), stablecoins and crypto (USDC, USDT, BTC, ETH, SOL, PAXG), tokenized stocks, metals and bonds under one login, so a single consented session can read every position and normalize them into one holdings feed keyed by asset and account.

Which regulator sits behind Fasset, and how does that shape the integration?

Fasset FZE holds a Virtual Asset Service Provider license from Dubai's Virtual Assets Regulatory Authority (VARA), per the VARA public register, and the group serves emerging markets such as Indonesia, Pakistan and Turkey. We build on the account holder's own authorization, log every consent, and keep the data set minimized to what the integration actually uses.

How are the Fasset Card and Fasset Earn balances handled, since they move in real time?

Card authorizations from the Visa-rail Fasset Card and accruals from Fasset Earn (up to roughly 10% APY on eligible stablecoins, as the app describes it) are read as event streams rather than static snapshots. We design the sync around their update cadence so a poll does not miss an authorization or double-count an accrual.

Does the Fasset peer-to-peer side expose order and settlement records?

The P2P flow produces order, match and settlement states that we can map into a structured order ledger. We model the lifecycle of each order so partially filled and cancelled states reconcile against the wallet movements they create.

Where these notes come from

Mapped from the Google Play and App Store listings, the operator's own site and help centre, the VARA public register, and May 2026 funding coverage; checked in June 2026. Key sources: VARA public register — Fasset FZE, Google Play listing, CoinDesk on the $51M raise, Fasset P2P help centre. Compiled by the OpenBanking Studio integration desk, June 2026.

Source for the Fasset endpoints you need starts at $300, billed only after delivery once it runs to your satisfaction; or skip the build entirely and call our hosted Fasset endpoints, paying per call with nothing upfront. Either shape runs a one-to-two-week cycle — tell us which records you want and we will scope it at our contact page.