“Vibe coding” (the AI-assisted, intuition-led way of building, where you describe intent, let a model draft, and steer by feel) has a reputation problem in fintech. It sounds like the opposite of what a regulated business demands: deliberate, documented, controlled, auditable. Shipping by feel, in a company that has to justify every decision to a regulator, sounds reckless.
I have spent eight-plus years building in regulated fintech, leading mobile at an FCA-authorised acquirer and integrating payment gateways before that. Today I rely on AI for a large share of that work, and in practice the two are not in tension. They are complementary, provided the rigour sits in the right place.
The contradiction is in the wrong place
The instinct, when AI enters a regulated codebase, is to slow it down: fewer suggestions, more gates, every generated line treated as a suspect. That misreads what regulation governs. A regulator does not care how fast you type, or whether a human or a model wrote a given function. It cares about outcomes and evidence: that customer money is handled correctly, that personal data is protected, that you can show who changed what, when, and why, and that a named, accountable person stands behind it.
Regulation governs the envelope, not the keystrokes, and speed inside a well-drawn envelope is essentially free. Seen that way, the task is no longer “make the AI cautious” but “draw the envelope well, then move quickly inside it.”
Put the determinism in the guardrails, not the typing
The mistake is trying to make the act of writing code deterministic. You cannot, and with a model in the loop, even less so. Move the determinism to where it belongs: the constraints around the code. These are the guardrails I will not ship a regulated flow without.
- Typed contracts and schemas. Money as integer minor units, validated boundaries, never floating point for currency. The model drafts freely; the type system rejects nonsense before it runs.
- Tests as the specification. Encode the compliance requirement as an executable acceptance test before generating the implementation, with property-based tests for money arithmetic and limits. The model then writes toward a target it cannot argue with.
- Policy as code. Sanctions screening, transaction limits, and retention rules expressed as versioned, tested rules, not prose buried in a wiki no one reads.
- Audit logging in the framework, not the prompt. Immutable, structured event logs built into the platform, so every state change is recorded, whether a human or a model wrote the path.
- Reproducible builds. Pinned dependencies, locked toolchains, deterministic CI. “It worked in my chat session” is not evidence.
With those in place, vibe coding becomes safe, not because the model grew wiser, but because the system around it catches what intuition misses.
The audit trail is what makes AI output trustworthy
Here is the point most teams miss: the controls a regulator expects are precisely the controls that make AI-generated code reviewable. Version history, pull requests, code review, decision records, CI evidence. Auditors require them all, and they are also how you keep a model honest.
The paper trail that satisfies an auditor is the same paper trail that lets you trust a machine's work. Compliance and AI want the same thing: everything written down.
Every AI-assisted change still lands as a reviewed pull request, attributable to the person who approved it. The model accelerates the drafting; a human owns the merge. That is not bureaucracy bolted on after the fact. It is the four-eyes principle you already needed, now doing double duty.
What it looks like on a real flow
Take a KYC step: verifying a customer's identity document and screening them against sanctions lists. The requirements are clear and well documented, exactly the kind of bounded, specified work a model is strong at. The workflow I would run:
- Write the control down first, as acceptance criteria expressed as tests: what must pass, what must be rejected, what must be logged.
- Let the model draft the implementation against those tests.
- Review against the control, not against taste: does it meet the requirement, log the right events, and fail safe when something is wrong?
- Record the decision (an architecture decision record, or a substantive pull-request description) so the next engineer, or the auditor, need not reconstruct the intent.
The model provides breadth and speed; the engineer provides judgement and carries accountability. The flow ships in a fraction of the time and still survives an audit, because the evidence is a by-product of the process rather than a scramble at the end.
Where humans stay firmly in the loop
Not everything belongs to the model. Some decisions stay with a person, every time:
- Regulatory interpretation: what a rule means for this particular product is a judgement call, sometimes a legal one.
- Risk decisions: accepting a customer, releasing funds, overriding a block.
- Anything touching secrets or production money: the model drafts code; it never holds production credentials or moves real funds unattended.
- Data entering prompts: minimise and redact personal data. A customer's identity document is not context you paste into a chat window.
And the non-negotiable: a regulator holds a named, licensed individual responsible. An AI cannot be accountable. It is a tool, not a person on the org chart. Treat it accordingly, and most governance questions answer themselves.
A higher floor, the same ceiling
AI raises the floor on how fast you can move. Guardrails hold the ceiling on how much risk you can take. Vibe coding is not reckless when the recklessness has been engineered out of the surrounding system, when the types, the tests, the logs, and the review gate are each doing their job.
The fintechs that win the coming years will not be the ones that banned AI to feel safe, nor the ones that adopted it and skipped the controls. They will be the teams that take the discipline they already owed the regulator and use it as the foundation that lets them build quickly, with AI, and without fear.