Surface area
Every item below is a solved problem on its own. The difficulty is that they have to behave as one product, and the seams between them are where programmes fail.
34 concerns · 7 groups
- 01
The ledger
Decided first, because every product decision downstream inherits its assumptions.
- Double-entry accounting
- Multi-currency balances
- Postings, holds and limits
- Reconciliation against every external source
- Financial reporting and close
- 02
Moving money
Each rail has its own settlement timing, failure modes and reversal semantics.
- Domestic and cross-border payment rails
- Settlement and clearing
- Card issuing, authorisation and disputes
- Fiat on and off ramps
- Stablecoin and on-chain settlement
- Foreign exchange and treasury
- 03
Custody and keys
The decision that determines whether the business is a product or a regulated custodian.
- Custodial and self-custodial models
- Key management and signing
- Wallet architecture
- Recovery without a seed phrase
- 04
Identity and permission
Cheap to bolt on and expensive to retrofit, because it has to sit inside the transaction path.
- KYC, KYB and ongoing due diligence
- AML monitoring and sanctions screening
- Identity and authentication
- Authorisation and entitlements
- Regulatory boundaries between entities and products
- 05
Risk
The system that has to disagree with the customer, correctly, in real time.
- Fraud detection and intervention
- Transaction risk scoring
- Exposure and credit limits
- Case management and evidence
- 06
The machine underneath
Where a correct design and a correct implementation diverge under load and partial failure.
- Event-driven architecture
- Transaction orchestration across services
- Idempotency, retries and replay
- Observability and audit trails
- Scale, latency and cost
- Security posture and key handling
- 07
What the customer touches
The only part anyone sees, and the part that reveals every disagreement underneath it.
- Mobile applications on both platforms
- Web application and shared APIs
- Onboarding and servicing flows
- Third-party banking and payment integrations
The integration is the engagement.
A vendor exists for almost every line above, and a competent team can integrate any one of them. Programmes do not fail on a single subsystem. They fail where two of them meet and disagree: the ledger and the card processor holding different views of an authorisation, the screening engine that cannot see the payment it is meant to gate, the mobile client rendering a balance the backend has not committed.
Those seams are not discovered during design. They are discovered in month seven, by which point the architecture that produced them is load-bearing and the cost of changing it is the reason the programme slips.
Deciding the seams before the build commits to them is the work. That is what we are engaged to do, and it is why the first deliverable of any engagement is a target architecture rather than a sprint.
Bring us the hard part.
Forty-five minutes with the people who would actually run the build.