"CTO in Focus" Toby Sucharov, Yaspa

In this CTO in Focus, Yaspa's Toby Sucharov reveals the engineering principles behind high-performance, high-stakes systems, from Playtech’s GPAS betting engine to Yaspa's real-time banking platform. He outlines why rigorous testing and meticulous observability aren't just good practice but essential to achieving flawless deposit journeys and spotting fraud in real time. As affordability checks and regulatory pressures reshape payments in iGaming, Sucharov shares how he balances innovation and caution, optimising conversion without sacrificing compliance.

Gaming Eminence: Across Playtech’s GPAS and now Yaspa’s instant-bank rails, what single engineering principle have you never bent—and where does it surface today in a metric operators actually watch, like deposit-success or fraud-hit rate?

Toby Sucharov: "Both gaming systems and financial systems need to operate correctly 100% of the time. With real-time platforms like these, defects and exploits can escalate almost instantly to large financial losses. Operators demand perfection and that requires an attention to detail to everything, one of the most obvious manifestations of this is testing. IT is about building blocks and solid foundations – for code this means the criticality of automated testing, be that unit or integration testing. Automated testing allows you to alter systems with confidence, so it’s the basis of agility and speed in IT.

However, financial systems are quite different to gaming systems. In gaming, the IT systems are rigid-controlled - you exist in a pure world of random number generators, wallets and codes - there are less moving parts and they can be controlled. With financial systems, Yaspa connects to over 2,000 banking institutions simultaneously – it’s a messy environment. Here the ability to monitor the system in real time is king. For us this goes past simple observability and logging.

We collect key events and complex data from every stage of a customer payment - to do this we ingest hundreds of millions of events and process them in real time in an OLAP cube. We know in real time not only which merchants and that banks are having issues, but at what point in the user journeys these failures occur. We have done a ton of work to understand signals from the noisy financial environment.

This allows us also to improve user experience as we can see which pages customers aren’t converting through or find those customers who are just a little bit suspicious."

---

Gaming Eminence: From GPAS’s billion-event firehose to Yaspa’s real-time bank calls, which design decision is unmistakably “Toby,” and which operator KPI does it lift most during Saturday-peak traffic?

TS: "The billion-event platform is the destination, and we need to talk about the journey - you need to understand the Principle of Commensurate Effort. IT systems often start small - perhaps one agile team in the corner of a room quietly tapping away on keyboards to the bemusement of everyone else in the office. But the systems I helped build at William Hill and Playtech ended up as core parts of those companies. In the end, you have hundreds of people working on those systems. It might take a few crazy pioneers to start one of these systems, but it takes a village by the time you’re finished.

So when you start do you consider this is going to be a business-critical financial system that will handle billions? Or are you those developers in the corner of the room? My north star on all these journeys is what I call the “Principle of Commensurate Effort”. You only need to ask one question: “How much money would I lose if the system is down for a day?”. You can substitute that for any disaster scenario of your choice, it might be the cost of a failed release.

Day 1 the cost of issues is almost zero as the system isn’t live. Here you can move fast with Agile processes, move fast and break things, but at the end of the journey the straight up financial loss from a lost day will be in the tens or hundreds of thousands of pounds. To cover that risk it makes sense to hire another tester, to check more, to have more processes. The inevitable conclusion is processes are not only project dependent but the life-stage of the project dependent. We’ve gone down a path which seems simple - but how many companies apply policies at a company level?

Often one of the core jobs when building these systems is projects off in an agile manner, and then maturing processes and accruing people as you go along - you’re building the village."

---

Gaming Eminence: Open-banking possibilities and looming UK affordability checks; what personal framework stops you seesawing between rapid release and regulatory rigour?

TS: "When we build IT systems, we build them in ways which allow us to update them easily. This rigor allows for rapidity. But regulatory rigour is always top priority – in terms of what is currently expected.

However, when we talk about affordability we’re talking really about what is possible in the future. Here I’m less concerned personally with the current regulatory plans. What excites me more is can we build tools that will aid sustainability in iGaming, while monitoring for financial harm? The answer here is without a doubt.

With Open Banking and consented access to a customer’s account we can easily analyse income and provide an affordability check. But the question is why would we want to do that? The answer is to look for financial harm, but financial harm is almost by definition a disruption of banking activity, and when we have access to a customer's records, why not just tell you if the customer is in financial distress? Is their balance negative? Have they missed recurring payments? Has the customer been gambling at multiple sites?

We will do the affordability checks, but Yaspa can also demonstrate that bank data is the ball game in terms of detecting financial risk. I don’t expect this to affect regulations in the foreseeable future, but I do hope we can acknowledge along the way the effectiveness of the approach."

---

Gaming Eminence: Financial-risk checks could bolt extra data calls onto customers. Which design move are you backing inside Yaspa to absorb that load without denting conversion—and how did you win over colleagues who feared player drop-off?

TS: "The UKGC is currently trialling frictionless CCJ checks. This is an interesting light-touch approach, but County Court Judgements is really just a small starting point. But any further checks will require customer informed consent, which is the right thing to do.

In terms of informed consent there are options. If a customer is asked to upload a bank statement, data suggests there is generally less than a 20% compliance rate, similarly a KYC request to perform an open banking check might be 40%. These numbers are extremely problematic for the industry - what happens if the customer doesn’t share?

Yaspa is solving this problem by merging our consented request to access bank data as part of a deposit journey. Here the customer themselves makes the decision to make a payment, they know they will be going to their bank to do that – they are in the driving seat. As part of this flow Yaspa will add the request for open banking consent onto that call and the customer will approve this as part of the payment. Conversion rates here are higher still - around 70% - and we need to consider payments never have a 100% conversion rate anyway.

So much of this product is intuitive with simple narratives, and most importantly it works – colleagues have been on board with this since the whiteboard stage."

---

Gaming Eminence: Which quiet shift—PSD3’s tighter APIs, variable-recurring payments, or the next Faster Payments upgrade?

TS: "PSD3 is exciting for the industry. I personally think VRP has amazing applications for monthly payments and bills. As we’re talking about Igaming I’m a little more cautious – I can see some limited applications such as buying weekly lottery tickets, but generally I’d have concerns about a wider usage. Open Banking for payments is in a good place at the moment, more standardised rollout across Europe would be welcome but I’m generally content.

However, what I would love to see is address and date of birth information supported as standard across all banks. This will hopefully be part of the Future Entity discussions happening in 2026. With these in place, Open Banking becomes perhaps one of the best and most effective KYC tools.

One key aspect of KYC is tying customers to their payment methods to check they are the same entity - that they are allowed to use that payment method. When Open Banking supports address and DOB, all that information can come from one place, one trusted source where companies leverage that high-trust relationship that exists between the customer and the bank to verify that customer. This is exciting."

---

Gaming Eminence: Finally, what daily habit keeps you thinking like the punter tapping “deposit,” not the CTO reading a protocol spec?

TS: "I’ve used different strategies over the years. When I was building automated sporting pricing systems at William Hill we were very concerned about shrewd punters being able to beat our prices. So I wrote myself a betting bot that would check football markets in Asia and place bets when its inbuilt model found value bets. That system placed £3 bets, over a month it bet £1,002 and won £1,006 - a £4 profit. It taught me a lot about how people look for value in betting systems.

This project failed my McDonald’s Test – the success of an IT project can be judged by whether you’d have earned more money just working at McDonald’s instead.

This is just one user story, though, and the plural of anecdote is not data. Data is the key – every day first thing with my coffee I look through our events tracking system which analyses system performances. Some days I look at bank performance, some days merchants, some days drop-offs in various journeys. Yaspa staff are all familiar with me asking some overly detailed questions about why there is a decrease in settlement times at 6am on a Monday in the Netherlands.

To get to such large financial systems you need to go through 100s of releases – and the faster you can get that done the better. IT is about speed, and speed is about partially about risk. If you have an IT system that’s processing hundreds of millions - or even billions - in bets or payments, then any issue with that system will cause a massive potential financial loss. You need to put a commensurate amount of effort into testing that system.

But instead of checking more, you change your risk profile, build systems where new features can be turned off, or released to a single merchant at once. Make sure rollback plans are solid. These mitigation plans aren’t about using the plans themselves, it’s about changing the risk profile so you can release with less effort put into checking that release. Facebook’s motto used to be “move fast and break things”, I would say “minimise downside, so you can move fast and break things with a limited blast radius”.

But there is another important point. At one point the William Hill pricing system, GPAS and Yaspa were small systems with few customers. At the beginning there was no risk as there were no customers. Therefore, the principle of commensurate effort tells us we need to be much less careful. And here we get to processes – at the start where risk is small processes can be ultra agile - People over processes, collaboration over documentation. That’s not true for the large system, documentation is critical, playbooks for disaster recovery are mandatory.

I’m going to borrow from an old work colleague, Gav Winter, and his “Dr Pepper” approach to IT – always ask yourself “what is the worst that can happen?” - then minimise that."