One ledger, and rails you can unplug.
A single wallet carrying fiat and crypto balances alongside issued cards — arranged so that opening a new market means changing a provider, never rebuilding the product.
The product most tightly bound to its first jurisdiction.
Few things are harder to carry across a border than a wallet. Moving money and issuing cards are licensed activities, granted one country at a time, and whichever banking partner a team integrates first has a habit of quietly becoming the architecture. Its assumptions settle into the data model, the reconciliation logic, the onboarding flow. By the time a second market reaches the roadmap, unpicking them costs more than the original build did.
The brief reversed that order. Treat every licensed dependency as a component to be exchanged per market, and hold the parts that genuinely belong to the product — the application, the ledger, the crypto layer — identical wherever it operates.
Licensed at the edges, uniform at the centre.
Every regulated dependency was pushed out to the boundary of the system. Money movement runs through embedded-finance providers that already hold permissions across many jurisdictions behind a single interface, and issuance sits on a platform spanning several regions and card networks. Either can be replaced, or run in parallel with another, without the application being aware anything changed.
Custody rests on MPC key material, which by construction has no jurisdictional anchor — there is no one country where the keys live. Card numbers are exchanged for tokens the moment they arrive, so the application never holds a PAN and stays outside PCI scope in every market it reaches.
One application, any market.
A double-entry ledger indifferent to denomination treats every balance as the same kind of object, whether it represents fiat or a token. One service layer speaks to whatever rail happens to be live for that user, and adding another leaves the ledger entirely untouched.
Residency requirements are met by region-segmented infrastructure that pins records where local rules demand, without forking the codebase to do it. Key management on KMS and HSM, held to a SOC 2 trajectory, clears most regulators without market-specific rework.
The rail, the issuer and the custodian each change per market. The application, the ledger and the crypto layer never do.
Project record
- Client
- Withheld under NDA
- Sector
- Fintech / payments
- Regions
- APAC
- Engagement
- Full build
- Platforms
- iOS · Android
- Ledger
- Double-entry, currency-agnostic
Confidential · anonymised
- React Native
- TypeScript
- NestJS
- PostgreSQL
- Card issuing
- Token vault
- MPC custody
- AWS
What shipped.
The properties the system holds today, rather than the ambitions it started with.
- Double-entry ledger indifferent to currency and asset class
- Virtual and physical issuance from a single platform
- Card data token-vaulted, keeping the application out of PCI scope
- MPC custody carrying no jurisdictional dependency
- Region-pinned residency without forking the codebase
- KMS and HSM key management on a SOC 2 trajectory
Other systems we have built.
Every client is under NDA. What we publish is the shape of the problem and how it was solved.
Have a system like this on your hands?
Tell us what you're trying to ship. We'll tell you honestly whether we're the right team for it — and what it would take.
Prefer email? info@triyant.sg
We reply within one business day. Your details are used only to respond to this enquiry and are never shared with third parties.