Onboarding and compliance checks
KYC, KYB and AML screening results mapped onto the customer's lifecycle, so an account can only open, or stay open, in a state compliance has approved.
Case study · client under NDA
Banking orchestration for a European payment platform
One system of record across identity checks, digital-asset custody, the ledger and banking rails, so every customer, every transfer and every balance has a single, provable answer.
ClientEuropean payment platform (NDA)
ScopeOrchestration core, integrations, back office
StatusIn production
The problem
Four regulated providers. Four versions of the truth
A fintech offering accounts, payments and digital assets doesn't run on one system. Identity checks happen at one provider, custody at another, bank accounts and payments at a third, and the business needs its own ledger on top. Each has its own API, its own states and its own ways to fail.
Money and personal data move between all of them. When a provider's event arrives twice, arrives late or doesn't arrive at all, balances drift, customers get stuck half-onboarded, and compliance has an incident to explain.
The client needed one layer that owns the process end to end: it decides what happens next, records why, and can prove it to a partner bank or a regulator afterwards.
What we built
An orchestration core between the business and its providers
- Customer apps & ops consoleweb · mobile · back office
- Orchestration corestate machines · idempotent commands · retries · webhook replay
- SumsubKYC · KYB · AML screening
- Fireblocksdigital-asset custody · transfers · policies
- Ledgerdouble-entry postings · source of truth for balances
- BaaS providersaccounts · IBANs · payments
- Audit trail & reconciliationevery change · every provider event · alerts
Digital-asset custody
Transfers started from the orchestration core under its rules, with custody callbacks matched back to the request that caused them.
One source of truth for balances
Every movement posted to the ledger, so balances are derived from history rather than overwritten, and can be explained line by line.
Accounts and payments
Account opening, payments and statements from banking-as-a-service partners, reconciled against the ledger.
Each part is also a service of its own: KYC and KYB onboarding, Fireblocks custody, ledger and reconciliation and banking-as-a-service integration.
How it holds up
The engineering a partner bank asks about
These are the same questions we put to every system in a Readiness Review, because we have had to answer them ourselves.
Exactly-once effects
Every command carries an idempotency key, so a retry never sends money twice or opens a second account.
Webhooks you can replay
Provider events are verified, stored before they are processed, and can be replayed after an outage.
Explicit states
Customers, transfers and payments move through defined states. Nothing is “probably done”.
Reconciliation
The ledger is checked against what each provider says happened, and differences raise alerts instead of hiding.
Audit trail
Who or what changed each record, when, and on which provider event, ready for a partner's or regulator's questions.
Provider failure is normal
Timeouts, retries and degraded modes are designed in, so a bad hour at one vendor doesn't become the client's incident.
Under NDA. The client stays unnamed. After an NDA is signed, we walk you through the architecture and volumes on a call.
Free 30-minute call
Tell us what has to work, and by when
You talk to an engineer who would work on it, not a salesperson. You leave the call knowing what it would take and what the first step costs, or we tell you that you don't need us.