Regulation Is Becoming Technical Infrastructure

This is the fourth of seven follow-ups, each taking one trend from our 2026 outlook and pushing past the headline into the part that changes how an operator actually runs. Trend #4 was that regulation has stopped being a document you read once and store in a binder and become a set of properties your platform has to demonstrate, continuously, in production. The headline - "there is more regulation" - is true and unhelpful. The sharper question is the one that separates those two firms: are you satisfying each obligation by bolting evidence on afterwards, or by building it into the system so the proof is already there?

For a long time, compliance was a translation job. A regulator wrote a rule in prose, a compliance officer interpreted it, wrote a policy, and the policy sat alongside the product. The system and the rulebook lived in separate worlds, connected by a person and a quarterly report. Call that the bolted-on model: the rule is satisfied next to the product, by people, after the fact.

That model is breaking down because the newest regulation is no longer satisfied by a policy document. It asks for things only a system can produce: an incident reported inside a fixed number of hours, an immutable record of who approved what, a register of every third-party dependency, evidence that a model behaved within stated bounds. You cannot answer those with a Word file. You answer them with architecture.

So there are two ways to meet the same obligation, and the contrast runs through everything that follows. Bolt it on, and every audit is a reconstruction project. Build it in - treat each obligation as a feature with an owner, a data model and a test - and the evidence becomes a by-product of running the business. The firms that get this right are not the ones with the longest policies; they are the ones whose platforms can show their work on demand.

Take DORA first, because it is the cleanest case of a rule you cannot bolt on. Under DORA - Regulation (EU) 2022/2554, which has applied since January 2025, financial entities across the EU have to demonstrate that their information and communication technology can withstand, respond to and recover from disruption. This is not a statement you make; it is a capability you evidence.

In practice that means concrete engineering obligations. You need a maintained register of your ICT third-party providers, because a regulator can ask which outside dependency sits behind which critical function. You need ICT incident classification and reporting on a defined clock, which forces detection and escalation to be built into your operations rather than improvised. You need resilience testing on a schedule. And you need contractual and exit arrangements with critical providers that you can actually act on.

The point for an operator is that every one of those lands on the platform and the team, not the policy shelf. Your platform security and ICT controls are now the thing being supervised, and a core banking stack that already treats access control, logging and recovery as first-class features starts a long way ahead of one that bolts them on after an incident.

DORA is not alone in being written for builders. Two adjacent regimes push in the same direction, and each forces the same bolted-on-or-built-in choice.

MiCA - Regulation (EU) 2023/1114 regulates crypto-asset activity in the EU, and much of what it asks for is operational rather than philosophical: safekeeping of client assets, complaint handling, conflict-of-interest controls, transparent disclosures. For a crypto-asset service provider these are not aspirations - they are functions that have to exist in the system, with records to match. The regime defines the perimeter; the platform has to live inside it.

The EU AI Act - Regulation (EU) 2024/1689 extends the same logic to the models many fintechs now run in credit, fraud and onboarding decisions. Where a use is treated as higher-risk, the obligations are again technical: risk management, data governance, logging, human oversight and documentation of how a system reaches its decisions. If your fraud engine or credit model influences a customer outcome, "the model said so" is not an answer a supervisor will accept. You have to be able to show the inputs, the controls and the override path.

The common thread across all three is that the obligation is discharged by the system, continuously, and proven from its records. That is what we mean when we say regulation has become technical infrastructure: the rulebook now reads, in places, like a specification. Laid side by side, the contrast is stark - the same obligation can be bolted on and reconstructed for an examiner, or built in and produced as a by-product of normal operation, and the built-in column is the cheaper one to live in.

The right-hand column is not a slogan; it is a design stance, and this is where it pays off. The expensive way to comply is to run the business, then reconstruct what happened when a regulator or auditor asks. The maintainable way is to design the system so the record is a by-product of normal operation.

That starts with the unglamorous parts. Your AML and KYC controls should write a complete, tamper-evident trail of every check, decision and exception as they happen, not retrofit one for an examiner. Your reporting and analytics layer should be able to produce supervisory and management figures from the same source of truth, so the numbers you run the business on are the numbers you report. Done this way, an audit becomes a query, not a project.

This is the practical case for RegTech, and it is less about buying a tool than about a design stance: instrument the platform so that proof is automatic. Treat every regulated action as an event worth logging, give each obligation a clear data owner, and make the audit trail something the system maintains rather than something a team assembles under deadline. The cost of compliance falls not when you write better policies, but when your platform stops needing humans to manually evidence what it already did.

The bolted-on-or-built-in choice lands differently depending on what you run.

For payment institutions and EMIs, DORA is the immediate obligation: ICT risk, the third-party register, incident reporting and resilience testing are live requirements, and they sit on your platform and operations team. Map them to features and owners now. Getting the licensing scope and operating model right at the start makes the resilience obligations far easier to evidence later.

For crypto businesses, VASPs and CASPs, MiCA and DORA stack: the conduct and safekeeping obligations of one and the resilience obligations of the other apply together, and both want the same thing - controls in the system and records to prove them.

For lenders and any firm using models in credit, fraud or onboarding, the AI Act is the one to read early. Decide which uses are higher-risk and build the logging, oversight and documentation before the model ships, not after a complaint.

For founders, the trap is treating compliance as a cost center you bolt on near launch. It is now a set of platform capabilities. Designing them in from the architecture stage is cheaper, faster and far more defensible than retrofitting them under examination.

The headline - there is more regulation - is true and, by now, not very interesting. The operating consequence is the choice between those two firms a week before an exam: the one reconstructing the evidence and the one running a query. Building it in is not abstract - it is a short checklist you can apply to every obligation. Give it an owner, so a named person is accountable for the control. Give it a data model, so the system records the obligation in a structured, queryable form. Give it a test, so you can show it works before a regulator asks. And give it an audit trail, so the proof is a by-product, not a project. DORA wants demonstrable resilience, MiCA and the AI Act want controls and records, and all three reward the same discipline. Compliance is no longer a document you keep. It is a property your system has to prove.

This is the fourth in a seven-part series expanding on our 2026 fintech trends. If you are weighing how these obligations land on your platform and license, speak to our team - we have done it across 100+ licensing and platform builds.