Financial Services Regulation

Definition

Financial services regulation imposes obligations that shape architecture directly rather than merely constraining it.

The requirements with architectural consequences

Immutable record-keeping with long retention. Transactions, communications and decisions retained for years in a form that can be produced on request. This favours append-only designs and makes deletion — including for privacy rights — genuinely difficult, resolved field by field with pseudonymous references.

Reconciliation as a standing obligation. Positions and balances must be verifiable against independent sources, daily. This is not error handling; it is a designed, monitored process, and it is the mechanism that catches every bug you have not thought of.

Demonstrable operational resilience. Not "we have a DR plan" but evidence that recovery has been tested against stated impact tolerances, with regulators increasingly asking for the test results.

Third-party and concentration risk. Dependence on a provider must be assessed, and for material services a documented, credible exit plan is required. That has a direct architectural implication: provider-specific managed services in a critical path must be justified against the exit obligation, which favours managed versions of open interfaces.

Change control with evidence, though increasingly automated gates are accepted in place of manual approval boards where the automation is demonstrable — which is a better outcome for delivery and for safety.

Explainability of automated decisions affecting customers — credit, pricing, fraud — including a route to challenge one.

The architecture that follows

Event-sourced or append-only records where history is the subject matter, since a mutable "current status" column cannot answer questions about what was known when. Strong consistency on the money path, with everything else — reporting, search, dashboards — explicitly eventually consistent. Reconciliation built in from the start rather than added after the first discrepancy.

Failure scenarios

• Mutable transaction records, so history cannot be demonstrated.
• No reconciliation, so discrepancies are found by a customer or a regulator.
• DR documented but never tested against the stated tolerance.
• A critical dependency with no exit plan.
• Automated decisions that cannot be explained or challenged.

Interview question

"Why does an exit plan requirement change your technology choices, and what would you do differently?"