The Gap AI Automation Who we work with Approach Fintech Garden Blog Start a conversation

Becoming AI Led: What Paysafe's CTO Actually Learned From the Inside

2026-09-17 By Dumitru Condrea | Ex-General Manager for Solaris Bank, Regulatory Architect Strategy
"The only real metric that matters to me is: did it add to the company's top line or improve the bottom line."

That line came from Ahu Chhapgar, CTO at Paysafe, on the season opener of Fintech Garden (episode 173, hosted by Igor Tomych and our own Dumitru Condrea). Chhapgar has run engineering at PayPal, Mastercard and Citi before Paysafe, so when he talks about what AI actually does inside a payments company, it is worth stopping and listening rather than nodding along to another AI roadmap slide.

The number everyone will quote, and the number that actually counts

In July, 64% of all code shipped at Paysafe was AI generated. That statistic will show up in a hundred conference decks this year, ours included, because it is a clean headline. But Chhapgar himself pushed back on treating it as a trophy. He called it a directional metric, useful for tracking adoption, useless for proving value. The number that matters sits one layer down: did the output move revenue or cut cost. A company can ship an enormous share of AI generated code and still be no better off than before, if nobody checks whether any of it changed a business outcome.

For fintechs and EMIs running lean teams, this distinction is not academic. It is easy to celebrate an internal tool that "uses AI" without ever measuring whether it replaced a headcount, sped up an onboarding queue, or reduced a false positive rate in transaction monitoring. Adoption metrics feel good. Only outcome metrics justify the spend.

When the bottleneck moves, it does not disappear

Igor asked Chhapgar the question most transformation pitches skip: what has not worked. His answer was candid. Nothing failed outright, but the sheer throughput of AI generated code turned code review into the new constraint. Engineers were not writing less, reviewers were reading more, and the team had to keep hunting for wherever the next bottleneck landed.

That pattern generalizes well beyond software. Automate a compliance intake process and the bottleneck moves to whoever signs off on exceptions. Automate KYC document parsing and the bottleneck moves to whoever resolves the edge cases the model flags. AI transformation rarely removes work. It relocates it, usually toward judgment calls that still need a human name attached to them. Any operational readiness plan that assumes automation deletes a queue rather than moving it downstream is going to be surprised in month three.

The real blocker is people, and it starts at the top

Dumitru raised a problem plenty of leadership teams recognize: boards approve a clean AI roadmap, and then internal resistance quietly stalls it, often from a department nobody expected to push back. Chhapgar agreed without hesitation that people, not technology, are the actual obstacle. His framing was simple: staff either feel threatened by the change or enabled by it, and which one they feel is set by tone from the CEO down, not by a training deck from HR.

This matches what we see with clients going through the same shift. Technical rollout plans get detailed timelines and budget lines. The human side gets a single slide that says "change management" and nothing else. If the CEO frames AI adoption as a cost cutting exercise, staff will act to protect their own function, and every rollout will meet friction that looks technical but is actually political. If leadership frames it as capability expansion, with a clear answer to "what happens to my role," the same rollout moves faster with the same tooling.

Risk segmentation, not blanket rules

On security, Dumitru pressed on something worth repeating to any board asking "is our AI safe": you cannot check code against a vulnerability nobody has discovered yet, and chained exploits are exactly the kind of risk that slips past a standard review. Chhapgar's practical answer was risk segmentation. Low risk internal tools move fast with light oversight. Anything touching PCI or PII goes through the same rigorous pipeline regardless of whether a human or a model wrote the code.

That is a good working model for regulated fintechs to borrow directly, and it lines up with where EU supervisors are already heading. DORA's ICT third party risk chapter (Articles 28 to 44) gives regulators the power to designate a vendor, including an AI or cloud provider, as critical, which pulls that vendor into direct oversight. If your AI tooling touches payment data, treating it as just another SaaS subscription is no longer a safe assumption. The vendor's own trust center page is marketing, not compliance evidence. The question a board should be asking is not "is this vendor secure," it is "can we demonstrate to a regulator, with our own documentation, why this system was in scope or out of scope for critical oversight."

Agentic payments: useful skepticism

Asked about agentic payments, autonomous agents initiating transactions on a user's behalf, Chhapgar was skeptical of near term profit impact but open to the long term case, once trust and liability questions get resolved. That is a more honest position than most vendor pitches in this space, which tend to sell certainty where none exists yet. Liability for an agent initiated payment gone wrong is not settled law in most jurisdictions, and until it is, treating agentic payments as a 2026 roadmap item rather than a 2026 production feature is the sensible call.

What this means for the rest of us

Chhapgar closed with advice that sounds obvious until you watch how many transformation projects skip it: start small, separate your real KPIs from vanity metrics before you start measuring, and do not let uncertainty stop you from actually going through the process. For an MSB or EMI weighing where to spend the next automation budget, the practical checklist from this conversation is short. Pick one process where you can measure a real financial outcome, not just an adoption number. Assume the bottleneck will move, not vanish, and plan for wherever it lands. Get the CEO saying, in plain language, what AI adoption means for people's jobs before the rollout starts, not after resistance shows up. And keep your risk segmentation explicit enough that you can show a regulator exactly why a given system sits inside or outside your critical vendor oversight.

None of that requires new technology. It requires treating AI adoption as an operational change with real consequences, which is the same discipline that was true before anyone called it AI transformation.

Full episode: Fintech Garden Pod 173, "Becoming AI-Led: Lessons from a Payments Company's AI Journey, with Ahu Chhapgar."

Evaluate your operations or compliance architecture

We clean up operational and compliance messes for licensed EMIs, PIs, MSBs, and PSPs, then design and implement the AI automation that keeps it clean. Explore our approach or request a diagnostic.

Book an operational diagnostic