A licensed Electronic Money Institution operating in Pakistan (name withheld under NDA)
FinSync Digital Wallet — an internal delivery codename, not a commercial product name.
The problem
The client's existing internal transaction model represented all payments with a single abstraction borrowed from card authorisation. RAAST settlement finality does not behave like card authorisation, and forcing both through one abstraction was producing subtle state bugs that were difficult to reproduce.
A large share of the user base transacts on congested mobile networks where requests time out mid-flight. The app assumed connectivity and handled its absence as an error state, which users experienced as the app losing their money.
Constraints we had to design within
- SBP regulatory requirements for an EMI, including AML/CFT screening obligations on the wallet itself.
- Median user device is a mid-range Android phone on a congested network.
- The wallet had a live user base — migration had to be transparent to them.
Approach
Separate settlement semantics explicitly
We split the internal transaction model so RAAST instant settlement and card authorisation are represented as distinct state machines that share infrastructure but not semantics. The bug class disappeared because the state confusion it depended on no longer existed.
Offline behaviour as a product decision
Conflict resolution was decided before the sync layer was written: which write wins, and who is told about it. In a financial context that is a decision with regulatory implications, and letting it be settled implicitly by arrival order is not acceptable.
Timed-out requests are reconciled against the server's authoritative view on reconnect rather than presented to the user as failures, which removed the single largest source of support contacts.
Screening inside the wallet, not beside it
As a licensed EMI the client carries its own AML/CFT obligations. Sanctions and PEP screening runs against the wallet's own customer record, with the same governed-threshold approach used in our banking work.
Engineering notes
Onboarding designed around the unhappy paths
Wallet onboarding is where most digital financial products lose their users, and almost never because of the happy path. Verification mismatches on entirely legitimate customers are common: names transliterated from Urdu have several valid Roman spellings, and honorifics and middle names appear inconsistently across records.
Exact string comparison against an authoritative record therefore rejects real people at a rate that surprises teams building it for the first time. Comparison is normalised aggressively, and near-matches are routed to review rather than refused outright.
Upstream verification services also have outages. Onboarding degrades rather than fails: the customer completes what they can and verification resolves asynchronously. A flow that dead-ends on an upstream timeout loses that customer permanently — they do not come back and try again later.
Tiered limits instead of a single verification gate
Assurance is modelled in tiers, each unlocking a defined level of capability, rather than as one binary gate. A customer who cannot complete a biometric check is not rejected; they hold a capped product with a documented route to upgrade.
This is better product and better compliance simultaneously. Regulators expect risk-based customer due diligence, and a single fixed gate is not risk-based — it applies the same friction to a low-value wallet as to full transfer capability.
Fraud controls that assume a shared device
Device-binding heuristics imported from markets where one person owns one phone behave badly where handset sharing is ordinary. Controls calibrated on that assumption generate false positives concentrated among lower-income users — the population financial inclusion is meant to reach.
Signals were weighted accordingly, with behavioural and velocity patterns given more weight than device identity alone.
Outcome
The settlement-semantics defect class was eliminated structurally. Timed-out transactions now reconcile automatically instead of surfacing to the user as failures.
Screening and monitoring obligations are met inside the wallet platform rather than depending on a partner bank's controls.
Figures above are drawn from delivery records held under NDA and are pending independent confirmation. Where a figure cannot be evidenced it will be removed rather than qualified.
Technology and standards
Services applied on this engagement
- Enterprise Mobile App Development
- Fintech & Payments Software Development
- AML/CFT Compliance Software Development