Case study 02 · Fintech
Financial technology platform
A lending and operations platform where product velocity could not be allowed to compromise the money path.
- Challenge
- New product surfaces were blocked by a core that could not be changed safely. Correctness, audit and disbursement had to hold while teams still shipped.
- Architecture
- Bounded services for origination, scoring, disbursement and operations, with audit events on every state change and a façade over the existing core.
- Engineering
- Idempotent disbursement, reconciliation jobs, contract tests against the current system, and release paths that treat the money path as a different risk class.
- Outcome
- Product teams shipped against stable contracts. The disbursement path stayed auditable. Change became a controlled release, not an all-or-nothing core rewrite.
Problem
A financial product organisation needed to move faster — new origination flows, better operations tools, more of the decisioning close to the product — without putting disbursement and books at risk. The core still ran the business. Every feature request landed as a change to the same system.
Context
Lending and disbursement systems accumulate rules that nobody wants to re-derive under pressure. Audit, reconciliation and controlled access were already obligations, not preferences. The useful move was to isolate the money path, then let product surfaces evolve against contracts.
Users
Credit-operations teams who need an accurate picture of an application and a disbursement. Product teams who were waiting on core releases. Compliance and finance stakeholders who need an audit trail that matches what actually happened, not what a dashboard implied.
Constraints
Money movement must be idempotent. Duplicate callbacks from banks and partners are normal. Roles, maker-checker and segregation of duties apply to operational tools. Releases that touch disbursement are a different risk class from releases that touch a marketing page. Historical loans cannot be “migrated later”.
Architecture
Origination, decisioning support, disbursement and operations became separate capabilities. The existing core remained the system of record behind a façade. Every material state change emitted an audit event. Operational consoles read from the same services as the product, with RBAC rather than a shared admin login.
Technology
Contract-first APIs, transactional outbox patterns for disbursement events, reconciliation jobs against partner reports, and automated contract tests that freeze the behaviour of the current core. Secrets, key handling and environment separation were part of the delivery path, not a production-week checklist.
Engineering challenges
Making disbursement retries safe. Explaining a decision later from data, not from a person’s memory. Keeping product experiments off the money path. Dual-running operational screens so a missed field did not become a missed payment. Defining compatibility so in-flight applications survived a release.
Solution
We extracted the origination and operations surfaces first, leaving disbursement behind the façade until the contracts were proven. Idempotency keys, reconciliation and audit were built with the first production path — not promised for a later phase. Release trains split “product” from “money movement” so the latter could move slower on purpose.
Outcome
New product work no longer required a core change for every screen. Operations had a role-aware console with an audit trail. Disbursement remained a narrow, tested path. The organisation could sequence change instead of choosing between freeze and rewrite.
Lessons
In fintech, speed is a property of boundaries. If every feature shares a ledger, there is no safe velocity. Audit is a product surface. Reconciliation is how you find out whether the architecture is telling the truth. Controlled change is an engineering design, not a process overlay.
Next
Let's build what comes next.
Have a product to build, a platform to modernize, or a complex technology problem to solve?