Thomas Reyes spent seven years running AML operations at BNP Paribas before making a move that surprised nearly everyone in his network: he joined Lyra Financial, a Paris-based payments fintech with 80 employees and no compliance infrastructure to speak of. Two years later, Lyra is fully authorised as a payment institution under French law, with a transaction monitoring framework that processes over 400,000 transactions a month. We spoke to Thomas about what that journey looked like from the inside.
Q: You spent seven years at BNP Paribas before moving to Lyra. What made you take the leap?
A: Honestly, it was a combination of frustration and curiosity. At BNP, I was managing a team of 22 people in the financial crime unit, which sounds impressive until you realise that 60% of your time is consumed by internal governance — committee decks, sign-off chains, legacy system workarounds. The actual compliance work, the thinking, the judgment calls, got squeezed into the margins. When a recruiter approached me about Lyra, my first reaction was scepticism. But then I had a conversation with the CEO, and what struck me was that she didn’t want a compliance officer who would just rubber-stamp things. She wanted someone who could help the business grow without blowing up. That’s a very different mandate, and it turned out to be exactly what I needed.
Q: What was the state of AML at Lyra when you joined?
A: There was essentially nothing formal in place. They had a KYC process that one of the product managers had cobbled together based on what he’d read online, and a spreadsheet for tracking suspicious transactions that hadn’t been updated in three months. They were operating under a banking partner’s licence at that point, so they had some coverage, but they were moving toward their own payment institution authorisation and needed a real framework. My first week, I just sat with people — engineers, product managers, the customer ops team — and tried to understand the transaction flows, the customer types, the risk concentrations. You can’t build controls until you understand what you’re controlling.
Q: Walk us through what building the transaction monitoring programme actually looked like.
A: The first decision was whether to buy a vendor solution or build something in-house. Given our volumes at the time — around 80,000 transactions a month when I joined — a full TMS platform like NICE Actimize or Nasdaq Surveillance was overkill and frankly unaffordable. But a spreadsheet was obviously not going to hold up with the ACPR. We ended up working with a regtech vendor that offered a configurable rules engine as a managed service, which gave us structure without requiring us to hire a dedicated data engineering team to maintain it. The harder part was writing the rules themselves. You have to make deliberate choices about thresholds — what triggers a review, what gets auto-cleared — and those choices need to be grounded in your actual customer risk profile, not copied from a bank’s typologies. Our customer base is largely SMEs in the e-commerce space, so the velocity patterns and average ticket sizes look nothing like retail banking. I had to rebuild my instincts from scratch.
“The hardest part of building AML from scratch isn’t technical — it’s resisting the temptation to just copy what you did at your last employer. The risk profile is different, the customer base is different, the transaction patterns are different. If you import controls designed for a retail bank into a B2B payments platform, you’ll either miss real risks or drown your operations team in false positives. Probably both.”
Q: False positives are a persistent problem in transaction monitoring. How did you manage that at Lyra?
A: In the first three months, our false positive rate was around 85%, which is actually not unusual for a new programme, but it’s unsustainable. Your operations team burns out, alert fatigue sets in, and the genuinely suspicious transactions get buried in noise. We took a very systematic approach to tuning. Every alert that was closed as a false positive got logged with a reason code, and every month I sat down with the data and looked for patterns. Were we over-triggering on a particular transaction type? On a specific industry segment? On payments to a certain geography? Over time, that feedback loop let us refine the rules significantly. By month six, we were down to around 40% false positives, and by the end of year one, we were closer to 25%. That’s still not perfect, but it’s workable, and critically, the quality of the alerts that do come through is much higher — the operations team trusts the system now, which changes how they engage with it.
Q: How did the ACPR respond when you went through the authorisation process?
A: I’ll be honest — I expected more friction. The ACPR has a reputation for being conservative, and the idea of a fintech walking in with a transaction monitoring system built on a third-party vendor rather than an established platform raised some eyebrows in our preparatory meetings. But what I found was that the supervisors were genuinely curious rather than obstructive. They asked very detailed questions about our rule logic, our escalation procedures, our SAR filing process, and how we documented the rationale for closed alerts. What they were really testing was whether we understood our own framework — whether the person sitting across from them had genuine ownership of it, or was just presenting a deck someone else had built. That’s a test I was prepared for, because I had literally built every part of it. The lesson for other fintechs going through authorisation is: don’t outsource your compliance knowledge to a consultant and then try to present it as your own. Regulators are good at spotting that, and it destroys credibility at exactly the wrong moment.
Q: What would you do differently if you were starting over?
A: I would invest in the customer risk assessment methodology much earlier. We built our transaction monitoring rules before we had a truly rigorous CRA framework, and that created problems — our risk segmentation was blunt, which made it harder to calibrate thresholds appropriately for different customer types. In hindsight, the right sequence is: understand your customer population, build the risk taxonomy, then design your monitoring controls around that taxonomy. We did it somewhat in parallel and had to do significant rework. I’d also push harder for compliance representation in product discussions from day one. There were a couple of product features that launched and then required retrofitting of controls because I wasn’t in the room when the design decisions were made. Getting a seat at that table isn’t about slowing things down — it’s about catching problems when they’re still cheap to fix.
Q: What’s your advice for compliance professionals at large banks who are thinking about making a similar move to fintech?
A: The skills transfer more than you think, but the operating model is completely different. At a big bank, you have specialist teams, legal resources on tap, established policies you can lean on. In a fintech, you are the specialist team. You will be drafting the policy, interpreting the regulation, and answering the CEO’s WhatsApp message about whether a particular partnership creates a financial crime risk — sometimes all in the same afternoon. If that sounds exhausting, it probably isn’t the right move. But if it sounds energising, then fintech compliance is one of the most intellectually stimulating environments you can work in. The other thing I’d say is: don’t underestimate the commercial exposure. You’re not just a control function; you’re a business enabler. If your framework is too restrictive, the business doesn’t grow. If it’s too permissive, the business gets shut down. You have to hold both of those truths simultaneously, and that requires a different kind of confidence than you develop in a big institution where someone else ultimately makes the call.