Industry
Financial services and fintech
In financial services the interesting engineering is in the controls: proving a customer is who they claim, moving money without ever losing track of it, and being able to reconstruct any decision months later for a regulator who was not there at the time.
Workflows
The work that actually happens here
Named the way practitioners in this sector name them, because that is the vocabulary a delivery team has to learn before it can be useful.
- Customer onboarding and due diligence
- Identity verification, sanctions and PEP screening, source-of-funds assessment and risk rating, with the evidence retained and the decision explainable.
- Ongoing monitoring
- Periodic re-screening and transaction monitoring producing alerts that reach a human queue with enough context to be decided.
- Payment initiation and reconciliation
- Moving money with idempotency, settlement tracking and reconciliation against provider statements — including the failure and partial-settlement paths.
- Dispute and chargeback handling
- Structured evidence collection against deadlines set by the scheme, with the outcome recorded against the transaction.
- Regulatory reporting
- Scheduled returns derived from the operational ledger, with the derivation reproducible.
Constraints
What changes the architecture
These are the reasons a design that works elsewhere would be wrong here.
Money movement must be idempotent
Any operation that moves money must be safe to retry. A network timeout that causes a duplicate payment is a control failure, not an incident.
Immutable ledgers, not mutable balances
Financial state belongs in an append-only ledger from which balances are derived. Updating a balance in place destroys the audit position.
PCI DSS scope must be minimised deliberately
Card data should never touch your systems. Tokenisation and hosted fields keep the compliance surface small; convenience decisions can expand it dramatically.
Regulatory change has fixed deadlines
Compliance deadlines are externally set and non-negotiable, which constrains sequencing more than internal priorities do.
Availability expectations are severe
Payment services are judged on availability during peaks. Degraded modes need designing rather than discovering.
Integrations
Systems we would expect to meet
- Stripe for international card acquiring and payouts
- Paystack and Flutterwave for Nigerian and Ghanaian payment methods
- Identity, sanctions and PEP screening providers behind a common interface
- Open banking providers for account information and payment initiation
- Core banking or ledger systems
- Accounting and reconciliation systems
Trust considerations
What users and regulators need here
- Explain what is being checked and why before asking a customer for documents; unexplained requests are the main cause of onboarding abandonment.
- A declined customer must receive a specific, actionable outcome and a route to human review.
- Sanctions and PEP screening outcomes require careful handling — a false positive is a serious customer harm.
- Financial and identity data need permissions beyond ordinary application access, including for internal staff.
- Retention of due-diligence evidence is set by regulation, which may exceed what the customer expects; the privacy notice must be explicit about it.
Architecture
A shape we would actually propose
A starting sketch, not a template. Discovery is what turns this into a specific design with recorded trade-offs.
- Ledger
- Append-only double-entry ledger in Postgres; balances are projections, never authoritative rows.
- Payment orchestration
- Durable workflows with idempotency keys, provider abstraction, and reconciliation against provider statements.
- Onboarding
- Configurable verification sequences per product and risk level, with a case-review queue for exceptions.
- Monitoring
- Rule- and signal-based alerting into a triage queue with full case context and recorded decisions.
- Segregation
- Financial and identity data behind additional permissions, with access logged and reviewable.
Outcomes
What good looks like
- Onboarding completion improved by explaining requirements before requesting documents
- Reconciliation breaks reduced by making money movement idempotent end to end
- Regulatory reporting reproducible directly from the ledger
- Audit evidence available without a manual reconstruction exercise
Related
Where to go next
Next step
A financial services and fintech project starts with the constraints
The Project Architect asks sector-specific questions about data, regulation and integration before it asks about features.