AI coding tools can generate a working feature in minutes, but in payments infrastructure, “working” and “safe to ship” are two different things. At TSH, we’ve talked to a fintech leader who understands that difference.
Move fast without the right guardrails, and the cost isn’t a bug ticket. It’s a regulator’s phone call.
To understand where the real risk sits, we talked to a CTO who governs AI code generation and adoption across a payments platform used by more than a hundred fintechs.
TL;DR
AI can be wrong while sounding confident, so verification has to be deterministic,
AI tooling never touches cardholder data, no exceptions,
The human in the loop approach means every change needs a named human owner, never a model,
Bring compliance early, and it becomes a backer, not a blocker.
Adoption is outpacing governance
Financial institutions are moving financial services AI into production faster than they're building the controls around it.
Wolters Kluwer's Q1 2026 Banking Compliance AI Trend Report surveyed 148 financial institutions.
It found that 31.8% of those institutions have already deployed AI or machine learning into production. Only 12.2% of them describe their AI strategy as well-defined and properly resourced.
That gap is where the risk sits.
For a payments company processing real money across fintechs and digital banks, an AI tool that writes fast but unreviewed code isn't a productivity win.
It's a potential risk waiting for a regulator to step in to ask about it.
AI can sound right and still be wrong
Marilyn McDonald has reframed how her engineers evaluate the output of AI code generation. She’s CTO of Thredd, a payments infrastructure company supporting more than 100 fintechs worldwide.
The old question was how fast something could be built. The new one is whether it should be built at all, and what “done” means.
That shift changes what a strong fintech engineering hire looks like. System design instincts, comfort with ambiguity, and speed of learning now matter more than framework mastery or memorized algorithms.
"The failures with GenAI happen when something looks credible and a human is too rushed to challenge it before shipping. [...] AI is still learning and makes bad calls sometimes. What matters is the guardrails you put in place to catch those moments." — Marilyn McDonald, CTO, Thredd
Senior engineers catch these errors because they’ve built systems from scratch and know what “right” looks like before the model tells them.
The harder problem is training the next generation to do the same, when their first job is often reviewing AI output rather than writing it from the ground up.
Where the guardrails have to be non-negotiable
Thredd handles real money across a hundred-plus fintechs and digital banks, so some rules don't flex regardless of how much time an AI tool could save.
McDonald draws the boundaries around a few things. They form the backbone of her approach to AI risk management.
Cardholder data never enters dev, test, or AI tooling environments,
Verification relies on deterministic tests and controls, not a human’s confidence in the output,
Every decision leaves a full audit trail, so it can be traced back if a regulator asks,
A named human is accountable for every change that touches a regulated flow.
"A human must say 'yes, I own this change' regardless of who drafted the code. [...] Where there's accountability, there has to be a person. Accountability is one thing you cannot hand off to a machine. At least not yet." — Marilyn McDonald, CTO, Thredd
Regulatory attestation works the same way for AI in banking deployments. AI can generate the supporting evidence, but someone inside the firm has to sign off on it.
That same line holds even when external vendors are speeding up fintech software development. Some things still can't be outsourced.
McDonald keeps roughly 70% of the work with employees and 30% with contractors as a baseline, flexing that ratio only in an emergency.
Accountability-critical work stays primarily internal, anything a regulator could ask about.
The harder question isn’t build versus buy. It’s visibility. It means knowing where AI is being used, which vendor tools are in play, and what data each one can access.
If a regulator asks for that inventory and it takes weeks to produce, that's the real failure, not the AI tool itself.
We’ve seen this play out with a traditional bank expanding into new European markets. Our case study on that AWS-powered bank expansion shows what it looks like when compliance shapes the architecture from the start, instead of reviewing it after the fact.
Making compliance a co-author, not a gatekeeper
The usual complaint about compliance is that it slows everything down. McDonald's answer is to stop treating it as a separate step.
Thredd runs on what she calls paved paths, pre-approved workflows within defined boundaries.
Once a flow like code generation in an approved environment is signed off, engineers don't need fresh approval every time they use it.
"The compliance team is an enabler when you bring them into the design process from the beginning. [...] The bottlenecking happens when you bring compliance people in at the end, show them something finished, and say you want to use it." — Marilyn McDonald, CTO, Thredd
The order matters more than the amount of process.
Bring compliance early, and they help design the guardrails alongside engineering. Wait until the end, and they have to review everything from scratch, with no visibility into how you got there.
Speed and control aren't opposites
None of this is an argument against using AI to write code in a regulated environment. It's an argument for treating speed and control as the same problem.
Don’t think that AI getting something wrong is a risk. Every tool has the potential to do something wrong eventually.
The risk is shipping that mistake because no guardrail was built to catch it, and no person was on the hook to notice.
If you want the full picture, you should read the original conversation with Marilyn.
The interview with Marilyn McDonald, CTO at Thredd.
Authors
Adrian Senecki
Copywriter and budding fiction writer, interested in (but not limited to) the business side of software development. Likes acquiring new skills and foretelling the future.
Andrzej Wysoczański
Frontend developer with 10 years of experience. With The Software House for almost 7 years, going from a regular dev to the Head of Frontend. He loves keeping tabs on the latest frontend technologies, especially React-related. Regular of the Taby & Spacje podcast (tsh.io/taby-vs-spacje) for Polish speaking programmers.