Cross-Border
Transfer Engine

A cross-border financial product cannot just be a wallet UI. Behind a single transfer sit multiple currencies, exchange rates, payment corridors, KYC, risk controls, provider routing, settlement, reconciliation and auditability.

That system — not the screen — is the actual engineering problem. It was built to model that honestly, end to end, before a single real rail is connected.

The customer app: a local-currency-first wallet, with USD, EUR, GBP and CNY alongside it. Add money, withdraw, send, receive, exchange, transfer across borders, and read the history of all of it. A visitor in Lagos sees naira first — not dollars converted for them.

The operational console behind it: customer operations, KYC review, AML and fraud, reconciliation, countries, fees and limits, and an audit trail. One system, two surfaces — because in a real financial product neither one works without the other.

• Display currency ≠ exchange — switching what a balance is displayed in is a viewing change, not a financial transaction. Actual conversion lives only in the Exchange flow. Collapsing the two is the classic way a wallet quietly lies to its user.
• 54-country data model — each country carries its flag, ISO code, local currency and symbol, dialing code, payment methods, payout partner and corridor status — so visibility and live connectivity are separate facts, never conflated.
• Multi-currency ledger — balances are modelled per currency rather than converted into one base at rest, which is what keeps the exchange path honest.
• Provider abstraction — routing sits behind one interface, so a corridor's payout partner is configuration rather than a branch in the transfer code.
• Passport KYC as state transitions — verification is a state machine with reviewable transitions, not a boolean — which is what makes the review queue in the console possible at all.
• Append-only audit trail — operational actions are written, never edited. Reconciliation reads that record rather than the mutable state.