Financial Services
In most software, a rare inconsistency is a defect to schedule. When the records describe money, it is a reconciliation break, a customer complaint and potentially a regulatory conversation. The engineering has to reflect that.
Money systems have their own rules
Distributed systems normally trade consistency for availability, and for most products that is the right call. Financial systems change the calculus. A duplicated payment or a lost ledger entry is not degraded service; it is a defect with a legal dimension, and eventual consistency is not an acceptable answer to a customer whose balance is wrong.
That pushes toward particular patterns — idempotency on anything that moves value, append-only ledgers rather than mutable balances, explicit reconciliation between systems, and integer arithmetic with defined rounding. None of it is exotic. It is simply non-optional here, and it is where inherited systems most often turn out to be fragile.
Where we work
Payments
Integration with schemes and processors, handling of the partial-failure cases that dominate real traffic, and reconciliation that surfaces breaks quickly rather than at month end.
Lending
Origination, decisioning and servicing, with the auditability to explain any individual decision long after it was made.
Core banking integration
Building modern services over cores that were not designed to be extended, without destabilising the system of record.
Regulatory reporting
Pipelines where the numbers reconcile to the source, the lineage is demonstrable, and a restatement can be produced without heroics.
Risk and fraud
Detection systems with tunable thresholds, clear analyst workflows, and honest measurement of the cost of false positives.
Customer platforms
Onboarding, identity verification and self-service, built to satisfy know-your-customer obligations without an abandonment rate that undermines the product.
Constraints that shape the work
Reconciliation is the acceptance test
If the ledger does not tie out against the source of truth on every cycle, nothing else about the system matters. This is the first test we write.
Idempotency everywhere
Payment paths get retried by networks, users and operators. Every write has to be safe to repeat, and that constrains the design from day one.
Immutable history
Corrections are new entries, never edits. Systems that update rows in place cannot answer the questions an auditor will eventually ask.
Change control is real
Release windows, segregation of duties and evidence. The pipeline has to generate that evidence, or a human will assemble it by hand under deadline.
Controls without paralysis
Regulated organisations often end up with change processes so heavy that shipping a small fix takes weeks — and the resulting batched, infrequent releases are considerably riskier than the frequent small ones the process was meant to protect against.
Better controls are usually automated ones. Segregation of duties enforced in the pipeline, immutable deployment records, environments that cannot be changed by hand. That satisfies an auditor more convincingly than a signature on a form, and it lets teams move at a reasonable pace.
- Idempotency and reconciliation designed in from the start
- Immutable audit trails covering both data and deployments
- Segregation of duties enforced automatically, not procedurally
- Disaster recovery demonstrated by rehearsal, with real numbers
When not to hire us
Maplecode holds no financial services certifications or regulatory permissions. We build systems for regulated firms; we are not a regulated firm ourselves, and we will not stand behind a control we do not own.
We also decline work where the deadline is a regulatory date and the scope is still moving three weeks out. Money systems fail loudly and in public. That combination needs a decision about scope, not a supplier willing to promise both.
Common questions
In most jurisdictions yes, and it is now common, subject to requirements around data residency, exit planning and oversight of the provider. The engineering questions are usually settled; the work is in the governance evidence. We would establish your specific obligations with your compliance function before designing, because the answer varies by regulator and by what the workload does.
Related work
Bring us the part that is stuck.
Send the constraint you are working around and we will come back with an approach, a rough shape of the work, and what it would take to hand it over.