Shortly
A payment stops halfway. The money has left one place and not arrived at the other. Whose is it right now? The FX partner’s? The wallet provider’s? The sender’s? That question is as much legal as it is architectural, and a platform has to answer it before it can be built.
In short. Damisa needed a payment orchestration platform spanning banking and stablecoin rails: money crossing banks, blockchains, and several partners on its way to a single recipient, with the books still closing at the end of the day. Neti designed how that money moves and who owns it at each step, then built the core that runs it: a self-hosted double-entry ledger, daily reconciliation against partners' reports, and a documented financial answer for every class of exception. The MVP was accepted in December 2025 and went into production, and Damisa’s own team has been extending it since.
About Damisa
Damisa is a British company providing cross-border payment services, mostly in the corridors where that is hardest - Africa, LATAM, the Middle East, and parts of Asia. Places where a payment can take days, pass through several correspondent banks, and arrive short by an amount nobody quoted at the start.
Its answer is to treat banking rails and stablecoin rails as one operation rather than two products. A payment is collected in one currency on one rail, converted, and paid out in another currency on another: one instruction at one price, whatever it crosses on the way. Damisa operates as a regulated entity, starting with a VASP registration in Poland and has since extended to other jurisdictions, Canada among them.
That is Damisa now - more than $25 million settled a month across 70+ currencies, and the first year its CEO has publicly described as passing €1m in ARR. (Sources: damisa.xyz, accessed 11 August 2026; Jordan Lawrence, LinkedIn, December 2025.)
In July 2025, the payments side was four people. A £2.25m pre-seed round had closed earlier that year to fund the build-out of the business, of which the payment platform was one piece. (Source: Fuel Ventures, 2025.) Neti was brought in for that piece: the layer that would have to hold every corridor, every partner and every currency the business was about to add.
Making two kinds of rail behave as one auditable system is architecturally hard. That difficulty belongs to the domain, not to any company working in it - and it is what the rest of this is about.
Who owns the funds at each stage?
Each rail defines a payment differently. A bank transfer settles on a schedule the bank controls, a blockchain transfer becomes final at a confirmation threshold the platform itself has to choose, and a gateway reports states that map onto neither. The same transaction can be complete in one system, pending in another, and waiting for an operational decision in a third, and all three can be right at once.
Beneath the question of the state sits the financial problem. Take one of the corridors designed for Damisa: a euros payment request settled by a payer sending USDC. The stablecoin arrives in a wallet on the paying customer’s side of the platform, moves to a master wallet, converts through a Regulated Liquidity Provider into euro, is credited to the customer’s euro account, and is paid out to an external bank account via their virtual IBAN.
For the customer, that is one instruction at one price. Internally, it is five separate balance positions, each with its own timing, fee, and evidence - and the first question such a design has to answer is not which API to call, but who owns the funds at each of those moments, including the moments where a transfer stopped halfway.
Answering the ownership question is what Neti was engaged to do. The core of this project was not code. It was a design: how money is represented, where it sits, what it passes through, and where value is removed from the flow. It was drawn as an explicit model before implementation started, and it is a part of the system that has stayed in place since.
The entity model, everything else is expressed in
The model starts with the question of what each object in the system is allowed to own. A Wallet holds funds on a chain and belongs to one customer. An Account holds a balance in one base currency. A Payment Instruction is not a balance at all - it is an obligation, something owed but not yet moved, and keeping it separate from the balances is what stops a pending transfer from being counted as money the platform holds.
Seven object types in all - Organization, Account (one per base currency), Virtual Account, Wallet, Master Wallet, Payment Instruction and Identity Account - each with a defined answer to what it owns and what it cannot.
The entity model is the least glamorous and most consequential decision in any payment system. Get it right, and everything downstream has somewhere correct to be recorded. Get it wrong and there is no downstream fix: the error is reproduced by every balance the platform computes from that point on.
A taxonomy of flows, hop by hop
Rather than treat payments as one generic pipeline, the design defines four flow types:
- stablecoins → stablecoins, no FX
- stablecoins → stablecoins with FX
- stablecoins → fiat
- fiat → stablecoins
Each hop was decomposed into its partner and ledger legs, and each hop was given a defined owner, a defined ledger entry, and a defined place in the exception model. The euro corridor above, written out the way the design writes it:
| HOP | Where the funds sit | Who owns them | What the ledger records | What can go wrong |
|---|---|---|---|---|
| 1. Payer settles the request in USDC | On-chain, in the wallet issued on the paying customer’s side for that request, in the MPC wallet infrastructure | The paying customers, attributable to that one payment request by the construction | Credit against the request is held until the confirmation threshold the platform defines for that chain | Under- or overpayment, funds arriving on the wrong chain, failed KYT, no gas to activate the wallet |
| 2. Sweep to the master wallet | Platform master wallet on-chain | Platform holds; the customer remains entitled, and the entry carries the Damisa entity handling the transfer | Internal transfer between ledger accounts, with the network fee posted as its own leg | Gas shortfall, partial sweep, movement attempted before the confirmation threshold is met |
| 3. Conversion at the liquidity provider, USDC to EUR | A position held at the FX partner | The platform’s position at the partner is still attributable to the request | Two legs - stablecoin out, euro in - recorded against the quote and the lock, with the spread visible | Quote expiry, rate movement between lock and execution, partner rejection or partial fill |
| 4. Euro credited to the customer’s account | Customer’s euro balance on the platform | The receiving customer’s | Credit to the customer’s euro account; the fee is retained here at the capture point defined for this corridor and swept afterward | Amount differs from what the partner reports - surfaces at the next daily reconciliation |
| 5. Payout via virtual IBAN | In the banking rail, until the receiving bank confirms | Leaves the platform; the obligation is extinguished on confirmation, not on instruction | Debit to the customer’s euro account, payout held pending until the partner confirms | Rejection, name mismatch, return or recall - returned funds have to be re-attributed to the original request |
The other three types differ in where the difficulty sits. Stablecoins-to-stablecoins without FX is the shortest path, and the one where attribution and gas, rather than conversion, are the whole problem. Stablecoins-to-stablecoins with FX adds the conversion leg with its quote, lock, and spread, without ever leaving the on-chain rail. Fiat-to-stablecoins inverts the corridor above: collection happens in the banking rail, where settlement runs on the bank’s schedule rather than on a confirmation threshold the platform controls, so the timing gap is carried in rather than out.
Where a fee can be taken without breaking reconciliation
In a multi-hop flow, the point at which a fee is taken is not obvious. Taking the fee earlier changes the amount that enters the conversion; taking it later leaves the platform bearing the rate movement and gas costs on funds already committed to the customer. The placement also determines how cleanly the resulting entry reconciles against what the provider reports.
Damisa owned the billing model and fee calculation: one end-to-end price per operation, fee plus spread, rather than a breakdown of internal hops. Neti’s scope covered the other half - triggering and retaining the fee at the designated points, and sweeping it afterward. That split is what allows for a single customer-facing price for a transfer that crosses several partners and two currencies.
Attribution by construction, not by matching
Attribution is where payment systems quietly degrade. Funds arrive, and the platform works out afterward whose they were - from the amount, the timing, or a reference the payer may or may not have set correctly. Two customers sending the same amount within the same window is enough to make it a judgment call.
On the digital-asset side, the design removes that guesswork by giving funds somewhere of their own to land. Every customer paying into the platform has their own wallet, and each payment request is issued a separate wallet for the duration of that transfer. What arrives therefore belongs to that request by construction, and so does everything spent against it: the gas to activate the wallet, the network fee to move the funds on, the fee retained on the way through. When the transfer completes, balances and retained fees are swept onward - which is what the gas tank and its automatic top-ups exist to keep running.
The two levels have to relate to each other, and that is what the ledger holds: a transfer wallet resolves to the customer whose request it served, and every entry carries the entity within Damisa’s organization entitled to handle that transfer. The account model is where those relationships live, which is why it is close to impossible to change once a platform is carrying live volume.
Regulatory obligations here sit with Damisa as the registered entity. What the design contributes is the record underneath them: movements attributable to one request and one customer by construction rather than by later matching, a full audit trail on each of those movements, and defined integration points for customer verification and transaction screening. Transaction screening - KYT, checking the counterparty and the on-chain flow, as distinct from KYC of the customer - is in the design because a registered participant has to identify the parties to a transfer and pass that information along with it under the Travel Rule.
Segregation per legal entity, present before it is required
At the time of the engagement, Damisa operated under a single license, so the model was built to prepare for segregation rather than to assume it: separate ledger entries, separately provisioned wallets, and separate keys per legal entity, ready before the requirement becomes binding.
For an institution already operating under more than one authorization, or in more than one jurisdiction, this is not a future concern. Client-money segregation, per-entity balance reporting, and the ability to demonstrate that funds held under one license never commingle with another are supervisory expectations rather than design preferences - and they are expressed in the same entity model as everything else. That is precisely why the property has to be in the model from the start. It cannot be retrofitted onto a platform already carrying live volume, because every balance and every reconciliation rule is derived from the model that lacks it.
Reconciliation is designed in, not added afterward
Reconciliation is often treated as something operations does after the fact - a report at month's end, a spreadsheet that finds the differences. On a platform where money passes through several partners on its way to one recipient, it is not a report. It is the only mechanism by which the platform knows what it actually holds, which means the ledger has to be built to be reconcilable from the start. It is not a thing that can be added once the money is already moving.
It was designed as a process: a daily comparison of the internal ledger against balances reported by partners, with discrepancies flagged and defined resolution paths for each class of mismatch, including manual-correction tooling and a full record of who changed what.
An exception taxonomy with financial answers
Exceptions in a payment system are not error handling; they are FinOps decisions with money attached. The design enumerates them and assigns each an answer: underpayment, failed KYT, wrong chain, mismatched outbound transfer, each mapped to a resolution, whether that is a manual credit, a refund or a confirmation.
One ledger, every leg recorded
Every movement described above is recorded in a self-hosted double-entry ledger: an account schema with a defined hierarchy, atomic posting, recording every money movement together with its partner legs, and real-time aggregation of balances per base currency.
The reason a financial-grade ledger matters here is simple. A standard database stores the current state and allows it to be changed in place. A double-entry ledger records balanced, immutable events and derives state from them, which is what makes a payment platform auditable rather than merely queryable.
What Neti built
Transaction processing. Orchestration of Payment Requests and Payout Requests, architectural integration of cross-rail transaction flows, migration of transaction processing from the pre-MVP version - including carrying the existing customer base and transaction history into the new account model without losing their relationships to each other - KYT transaction risk and monitoring, minimum payment value handling, FX calculation per corridor, use of provider quotes and locks, “you pay / recipient receives” calculations, and event publication to the API layer.
Exception handling and internal tooling. Centralized exception management with alerting, and dedicated internal tooling for the operations team, including handling for KYT failures and insufficient gas.
Ledger and financial operations. Ledger-account creation, transaction postings, real-time balance aggregation per base currency, daily reconciliation, discrepancy handling, fee retention and sweeping, and manual FinOps controls - redirecting affected funds, overriding ledger status from hold to available under internal approval, and posting manual entries to correct balances.
Wallet and blockchain operations. Tron wallet activation, the gas tank behind it, ERC-20 gas fee sponsorship, and creation of the virtual IBANs used for fiat payouts at the liquidity provider. The wallet layer runs on Ethereum and Tron with non-custodial MPC infrastructure.
Environments and integrations. Full sandbox and production environments, plus data-synchronization pipelines. Integrations with enterprise-grade KYT compliance, MPC wallet infrastructure, and regulated FX & fiat liquidity providers.
Where the line ran. Damisa’s team owned the Dashboard and Hosted Payment Page frontends, request creation including idempotency, provisioning of the virtual accounts customers pay into, wallet infrastructure provisioning and KYT compliance registration, wallet-to-account linking, fee calculation, platform-level rate locking, and reporting dashboards.
Four and a half months, and the one thing to do differently
Neti delivered the MVP in four and a half months, across three milestones, working inside Damisa’s own merge-request and code-review process with their team, seeing the work as it went.
The schedule moved along the way: as external partner API matured and secondary liquidity routes were introduced later than originally planned.
The thing worth doing differently is visible from here. Stubs and mocks were built where a provider had no usable sandbox, but they were built in response to each blockage rather than ahead of it, so the schedule absorbed the delay before the workaround arrived. On a platform whose partners are still building their own APIs, mocking every external dependency at the start - designing against a defined interface and treating the real integration as a later swap - decouples the design work from other people’s release dates. That is how the next one gets built.
The questions are the same everywhere; only the answers differ
Damisa’s platform was built for Damisa. The decisions underneath it, however, were not specific to Damisa - which is why they are set out here in this much detail.
Every institution moving money across banking rails and stablecoin rails has to answer the same set of questions before it writes any code. Which entity owns a balance at each stage of a multi-hop flow? How a payment decomposes into partner legs and ledger legs. Where a fee can be taken without breaking the reconciliation of the entry it produces. What a transfer that arrived on the wrong chain becomes. How the internal books are reconciled with what partners report, daily rather than at month-end. The answers differ by corridor, by license, and by partner mix. The structure of the answers does not.
Which is why the work is worth naming precisely. It is not integration work, and it is not a choice of tooling. It is the money model: the layer that determines what can be recorded, reconciled, and evidenced before a single provider is connected.
What this means for an institution operating under a license
Three properties of this architecture matter more to a supervised institution than to a startup, and they are the ones worth testing against any orchestration layer under evaluation.
The books stay inside the institution. The ledger in this build is self-hosted. Nothing about the platform’s financial state depends on a third party’s availability, retention policy or jurisdiction, and no external party holds the record of what the institution owes and what it holds. The principle generalizes: for a supervised entity, the record of balances and obligations - and that record’s residency - should follow the institution’s own footprint rather than a vendor’s.
Every correction is evidenced, not just every transaction. Manual FinOps action - redirecting affected funds, moving a ledger position from hold to available, posting a correcting entry - happens under internal approval and against a full record of who changed what and when. For a supervised entity, an intervention that cannot be evidenced is worse than no intervention at all.
Multi-entity structure is present before it is needed. Separate ledger entries, separately provisioned wallets and separate keys per legal entity, as set out in the segregation section above.
Where an institution’s own obligations sit - DORA on ICT risk and third-party arrangements, MiCA where digital-asset services are in scope, the Travel Rule on transfers - architecture is what makes those obligations evidenceable. It does not discharge them; they remain with the license holder. Which makes the useful question in a procurement conversation not what the vendor claims about compliance, but what evidence the platform produces on the day a supervisor asks for it.
Where this approach fits, and where it doesn’t
A financial institution isn’t buying the ability to write software. It’s buying someone who can model money moving across multiple partners, currencies and jurisdictions in a way that can be reconciled and audited. The hard part is the number of decisions that have to be right before the code is worth writing: who owns the funds mid-flow, where a fee can be taken without breaking reconciliation, what a transfer that arrived on the wrong chain should become.
On this project, that meant four flow types decomposed hop by hop, integrations across KYT, MPC custody, FX, and settlement partners - a self-hosted double-entry ledger, a daily reconciliation process with defined resolution paths, a documented answer for every class of exception, and full sandbox and production environments, including stubs for providers that offered none, delivered in four and a half months by a six-person team that included a dedicated architect and QA.
Where an institution’s money model is genuinely settled and the remaining work is executed against a finished specification, there are cheaper ways to buy that. Where it isn’t - and it usually isn’t, because the model is exactly where the corridors, the partners and the licence meet - the cost of getting it wrong is not a delayed release. It is a rebuild around a wrong answer on a platform already carrying live volume.
Related reading
- Blockchain Ledgers: The New Core for Tokenized Finance - the broader case for why fiat and stablecoin flows need one ledger, not two systems reconciled after the fact.
About Neti
Neti designs and builds the financial core underneath payment platforms: money models, ledger design, reconciliation, and exception handling.
Book a 45-minute payment architecture review. We’ll map your current rails, identify where reconciliation breaks, and outline a multi-rail design.
Discuss your payment architecture with Neti.
