Reaching account data inside Spring Development Bank's crypto-rail super-app

Spring Development Bank keeps two ledgers at once. A custodial portfolio of fiat and digital gold sits inside its super-app backend, and the SDB token settles on Polygon, a public chain. That split is the whole integration story here: one half is reachable only through a consenting session, the other is readable straight off the chain. An integrator who treats the app as a single black box gets a partial picture; pulling clean, reconciled data means working both halves and joining them.

SDB launched in 2023 as a blockchain neobank backed by Myanmar's National Unity Government, per Radio Free Asia and The Register. It takes deposits in US dollars, Singapore dollars, Thai baht and Myanmar kyat, with digital gold and term deposits layered on top — as its help center and DVB describe the live Phase 1 product. The list below maps where each of those surfaces actually originates.

Bottom line: the custodial portfolio is the harder, higher-value half, and it comes out through an authorized session against the production super-app. The token side is a public read off Polygon. We build both and stitch them into one normalized account view, which is what most callers actually want.

What the app holds, and where it comes from

Rate, payout and APR figures move, so we read them live rather than hard-coding any number. The Earn program's daily-payout model and the token's collateral-loan feature are taken as SDB describes them, not asserted as fixed terms.

Routes that fit this app

Consented super-app session (the portfolio half)

The custodial balances, gold, transfers and term deposits live behind the authenticated super-app. We analyze the mobile and web-service session — the login, token and cookie chain — and drive the same authenticated calls the app makes, under the account holder's authorization. This reaches everything the customer sees in their own dashboard. Effort is moderate; durability depends on release cadence, which we cover with the re-validation step below. Access to a consenting account is arranged with you during onboarding.

On-chain indexing (the token half)

SDB trades on Polygon, per MEXC and CoinCarp, and its contract is viewable on Polygonscan. Token balance, transfer history and staking events come from a public RPC node or a Polygon indexer with no credentials at all. This half is durable — chain data does not break on a UI change — and cheap to keep running.

Native export (fallback)

Where the portal offers a statement or transaction download, we wire that as a low-friction fallback for the records it covers. It is narrower than the live session but survives well and needs little maintenance.

For most callers the recommendation is concrete: run the consented session as the source of truth for the fiat-and-gold portfolio, and join it to a Polygon read keyed on the customer's wallet so the SDB token position is always current and independently verifiable. The export path is there for backfill. That join — custodial truth plus public-chain proof — is the design that holds up for this particular app.

Auth flow and a portfolio read

Shape confirmed during the build against the production super-app; field names are illustrative and pinned at delivery.

POST /api/v1/auth/login            # super-app session bootstrap
  { "identifier": "<phone_or_email>", "password": "<secret>", "device": "<id>" }
  -> 200 { "accessToken": "<jwt>", "refreshToken": "<rt>", "expiresIn": 1800 }

GET  /api/v1/wallet/portfolio       # custodial half
  Authorization: Bearer <jwt>
  -> { "balances": [ {"currency":"USD","amount":"...","unit":"fiat"},
                     {"currency":"SGD","amount":"..."},
                     {"asset":"GOLD","grams":"...","quotedPrice":"..."} ],
       "termDeposits": [ {"product":"6M","principal":"...","accrued":"..."} ] }

# token half, no auth, keyed on the customer's wallet
eth_call balanceOf(wallet) -> SDB token balance     # Polygon RPC / indexer
# reconcile: portal "SDB" line vs on-chain balance; flag staked / collateralized delta

on 401 -> refresh once with <rt>; on repeat, re-auth and alert (front-end drift)

Token refresh, the 401 retry and the reconcile step are the parts that keep a sync quiet in production. The reconcile is specific to SDB: the portal may show a token line that differs from the raw wallet balance because some is staked in Earn or pledged as loan collateral, and the join has to account for that gap rather than report a mismatch.

What lands at the end

• An OpenAPI/Swagger spec covering the portfolio, gold, transfer-log, term-deposit and token-reconcile endpoints as modeled above.
• A protocol and auth-flow report: the login, JWT and refresh chain for the super-app, plus the Polygon read path and the reconcile logic.
• Runnable source for the key endpoints in Python and Node.js — the authenticated portal client and the on-chain reader, joined into one account object.
• Automated tests against recorded fixtures, including the staked-versus-on-chain reconcile and the 401-refresh path.
• Interface documentation an in-house team can run and extend.
• Compliance and data-retention guidance for consent records and the data actually pulled.

Things we handle on the build

A few details of this app shape the work, and we account for each:

• SDB exposes separate web-service backends — dev and UAT super-app subdomains are visible alongside the production host. We use those only to confirm the auth shape, then pin the delivered client to the live host so balances are real.
• The token line needs reconciling against the chain. We design the join so a staked or collateral-pledged balance is labeled, not silently dropped or double-counted against the custodial figure.
• Four live deposit currencies and a gold unit mean every converted total carries an FX or gold-price snapshot; we timestamp the rate used so a valuation is reproducible.
• Term deposits and Earn payouts accrue daily, so the sync models accrual rather than reading a single static balance, and a daily run reflects the new postings.
• Front-end releases shift session details. A re-validation pass runs in maintenance to catch a changed login or token format early.

The authorization this rests on

SDB describes itself as licensed by the Interim Central Bank of Myanmar's National Unity Government — a body without broad international recognition. That matters for an integrator: the mainstream account-aggregation regimes (UK Open Banking, EU PSD2, Australia's CDR) simply do not extend to it, so there is no consent API to ride. The dependable basis for the custodial half is the account holder's own written authorization, captured and logged before any session runs. The token half rests on the public Polygon ledger, which needs no permission to read. We work data-minimized — pulling only the domains in scope — keep consent and access records, and sign an NDA where the engagement calls for it. Myanmar has no comprehensive data-protection statute in force, which makes the explicit consent record the anchor rather than a statutory carve-out.

Interface evidence

Store screenshots of the live app, useful for confirming the surfaces named above. Select to enlarge.

Where it sits among similar apps

SDB shares the crypto-plus-fiat neobank shape with a known cluster of apps; an integrator building a unified portfolio view often needs more than one of them. Named here for context only, not ranked.

• Wirex — Web3 money app holding many fiat balances and 200-plus crypto assets with card-spend conversion.
• Crypto.com — exchange and card platform with staking rewards and multi-currency spending balances.
• Revolut — multi-currency super-app combining fiat accounts, FX and crypto trading in one ledger.
• Nexo — custodial crypto accounts with interest-bearing balances and crypto-backed credit lines.
• Uphold — multi-asset wallet moving between fiat, crypto and metals in a single account.
• Xapo Bank — Bitcoin-focused bank pairing custodial crypto with USD deposit accounts.
• Wise — multi-currency account and transfer service holding balances across many fiat currencies.
• Cake DeFi — custodial platform for staking and yield across digital assets.

What was checked

Built from the app's Play and App Store listings, its own site and help center, and primary reporting from July 2023 onward; the token side cross-checked against market trackers. Reviewed June 2026.

• Spring Development Bank on Google Play
• SDB Help Center — registration requirement
• The Register — Myanmar's first crypto-based bank launches
• CoinCarp — SDB token (Polygon) market data

Mapped by the OpenBanking Studio integration desk · June 2026.

Integrator questions

Which Spring Development Bank balances live on-chain and which sit inside the bank's own ledger?

Two layers. The fiat and digital-gold portfolio (USD, SGD, THB and MMK, plus gold) is custodial, held inside SDB's super-app backend and reachable only through a consented session. The SDB token settles on Polygon, so token holdings, staking and transfers are readable from the public chain. A unified view reconciles both, and we build it to avoid double-counting the staked or collateralized portion.

Can the SDB token side be read without a customer account?

Yes. SDB trades on Polygon, per MEXC and CoinCarp, and its contract is viewable on Polygonscan, so token balances and transfer history come from a public RPC node or an indexer with no login. The custodial fiat and gold balances are a separate, authenticated surface and do need a consenting account.

What regulator covers Spring Development Bank, and does an open-banking regime apply?

SDB describes itself as licensed by the Interim Central Bank of Myanmar's National Unity Government, a body without broad international recognition, so the established account-aggregation regimes (UK Open Banking, EU PSD2, CDR) do not cover it. The dependable basis for the custodial side is the account holder's own written authorization and consent; the on-chain side rests on the public nature of the Polygon ledger.

Spring Development Bank runs separate dev and UAT web-service hosts. Which one does the build target?

Production only. The dev and UAT super-app subdomains are useful for confirming the auth shape during the build, but the delivered integration is pinned to the live super-app host so it reflects real balances. We add a re-validation pass for when the front end shifts between releases.

The work ships one of two ways for SDB. Take the runnable source — the authenticated portal client plus the Polygon reader, joined and tested — from $300, paid only once it is delivered and you are satisfied. Or skip the code entirely and call our hosted endpoints, paying per call with nothing upfront. Either way the cycle is one to two weeks. Tell us the app and what you want out of it, and we handle access and compliance with you from there — start a conversation here.