Chapter 08 · Part II — Sector applications
Financial services
Where authorisation correctness is the product, segregation of duties is a regulatory obligation, and change control was designed for a delivery rate that no longer applies.
Financial services has the most mature software control environment of any commercial sector, and it is the sector where the arithmetic of machine authorship bites earliest — because almost every control in it is a human-rate process sitting in the delivery path.
Section 01Typical workloads
- Payments and transfers
- Initiation, authorisation, limits, sanctions and fraud screening, settlementCorrectness is the product. An authorisation defect is not a vulnerability report; it is a loss event and a regulatory notification.
- Ledgers and reconciliation
- Balances, postings, adjustments, break investigationData that must be reconstructible and provably unaltered, where a schema change mid-flight is a routine and dangerous operation.
- Customer platforms and APIs
- Retail and business banking, third-party access, partner integrationsMulti-tenant by construction, with the classic failure being one customer's context reaching another's data.
- Financial crime operations
- Onboarding, screening, case management, suspicious-activity workflowHighly sensitive personal data, strict access segregation, and statutory retention that outlives the systems holding it.
- Risk and regulatory reporting
- Capital, liquidity, market and credit risk, transaction reportingDerived from many upstream systems; correctness depends on lineage nobody can fully enumerate today.
Section 02The threat picture
- Authorisation and tenancy defects. The dominant serious finding in this sector. Generated code chose the insecure implementation about 45 per cent of the time where a secure option existed[2], and roughly half of functionally correct generated backends were exploitable in a benchmark with executable exploits.[1]
- Volume outrunning change control. Four-eyes review, segregation of duties and release approval are all human-rate processes. AI acceleration does not remove them; it queues behind them, which creates pressure to make them nominal.
- Dependency compromise reaching regulated systems. The open-source graph is the same one everyone else uses. A self-replicating worm that touched hundreds of packages and thousands of secrets did not check industry codes.[7]
- Credential exposure through authoring tools. A single indirect injection has made major coding agents leak environment credentials at developer privilege.[9] In an estate where a credential is a payment capability, that is a different severity of event.
- Lineage and explainability gaps. Regulatory reporting requires knowing where a number came from. Machine-authored transformation layers accumulate faster than lineage documentation does.
- Third-party and outsourced delivery. Most code is written by suppliers, most suppliers now use AI coding tools, and contractual assurance does not change what the delivered code can reach.
Section 03What is used today, and where it runs out
| Control | What it covers | Where it runs out |
|---|---|---|
| Segregation of duties | Prevents one party from both initiating and approving | Enforced organisationally and in application logic that has to remember to check. Nothing structurally prevents a new path from bypassing it |
| Four-eyes review and change approval | Human judgement on every change, with an audit trail | A human-rate process in the delivery path. Under AI acceleration it becomes either the bottleneck or a rubber stamp — and both outcomes are visible in audit findings |
| SAST, DAST and SCA in the pipeline | Broad, cheap, repeatable coverage of known classes | Detection with an unquantified false-negative rate; produces a triage queue that scales with output volume while triage capacity does not |
| Penetration testing | Real adversarial evidence at a point in time | Samples a system that is replaced between samples |
| Operational resilience regimes | Forces impact tolerances and scenario testing | Excellent at "what happens when it fails". Says little about whether a class of failure was possible to write in the first place |
| Model risk management | Mature governance for models used in decisions | Largely aimed at models that make decisions, not models that write the systems that make decisions |
That last row is worth sitting with. Most institutions have rigorous governance for a credit model and comparatively little for the coding agent that wrote the platform the credit model runs on — even though the second has a wider blast radius.
Section 04What changes
Segregation of duties becomes a type-level property
Where the authority to initiate and the authority to approve are distinct, unforgeable values, code holding one cannot perform the other. That is the same control you have today, moved from a procedural assertion checked by audit sampling into a property that the build establishes for every path, including the ones nobody sampled.
Tenancy stops depending on discipline
When the authority handed to a request is scoped to one customer at the moment it is issued, code holding it cannot name another customer's data. The cross-tenant leak — the finding this sector fears most in a shared platform — stops being a defect a test might catch and becomes a program that does not compile.
Change control stops being the bottleneck
This is where the argument earns its keep. Assurance work that sits after writing is serial with delivery and therefore trades against speed. Assurance carried by the language is established when the code compiles. Four-eyes review does not disappear — it moves onto the questions where human judgement is decisive, which is where your reviewers would rather be spending it anyway.
Lineage becomes derivable
Where the compiler owns the boundary between tiers and the shape of the data, the path a figure took is a property of the program rather than a document maintained alongside it. That is directly useful to reporting obligations that currently rest on hand-maintained mappings.
Supplier delivery gains a technical floor
Contractual assurance transfers liability after the fact. A checked authority surface constrains what delivered code can reach regardless of who wrote it, which supplier's agent produced it, and whether the reviewer was having a good week.
Section 05Questions worth asking internally, and of suppliers
- Which of our controls are properties of the system, and which are statements about the process that built it?
- If our delivery rate rose by an order of magnitude, which controls become nominal — and have we already crossed that line anywhere?
- Can we enumerate mechanically what a given service is capable of reaching, or do we infer it from configuration and code review?
- What governs the coding agents in our suppliers' pipelines, and what bounds them if one is following instructions it read in a ticket?
- Do we apply anything resembling model risk management to the models writing our systems?
Kasuri is at specification stage, ahead of a reference implementation. There is no production deployment, no regulated user, and no certification. Nothing in this chapter is a claim of regulatory compliance or approval for any jurisdiction or regime; the properties described are design intent against the threat picture above. Chapter 20 sets out what early engagement involves.