iGaming Payment Processing: Why the FTD-to-Trusted Ratio Decides Your Approvals

By the CatalystPay team

 

Quick answer

When choosing an iGaming payment provider, your FTD-to-trusted ratio, the split between first-time deposits and repeat, seasoned traffic, shapes your approvals and processing stability more than your MDR does. Acquirers judge a book less on volume than on this ratio: one that's mostly unseasoned first deposits reads as fragile and high-monitoring, while one that seasons into trusted players reads as stable and worth keeping. It's also where acquisition and risk pull against each other, since the levers that lift FTD conversion are the ones that widen acquirer exposure. Get the ratio right across your target geos and from a cold start and approvals, chargebacks and long-term stability all move with it.

On this page

• Beyond MDR: the number that actually decides your acquiring
• FTDs vs trusted deposits, and the ratio your acquirer watches
• When does an FTD become "trusted"?
• You don't get to label your own trusted traffic
• Why acquirers read the FTD as the riskiest moment
• An FTD isn't geo-neutral
• What if you're a brand-new iGaming site with no trusted traffic yet?
• The conversion-vs-approval trade-off
• What a clean FTD flow looks like and what to expect from an iGaming payment provider
• How CatalystPay helps

Beyond MDR: the number that actually decides your acquiring

Most merchants choose a payment partner on the rate - MDR first, everything else second.

That's the wrong lens for high-risk. In iGaming, two operators can process identical volume at identical pricing and look completely different to an acquirer, because the rate card says nothing about the quality of the traffic behind the volume. The sophisticated question isn't "what's your MDR?" It's "what does my traffic mix look like to an acquirer, and is it improving?" (It's a point experienced iGaming payments leads make repeatedly - blended approval rates and headline MDR hide more than they show.)

That mix comes down to two words every experienced operator knows: FTD and trusted.

FTDs vs trusted deposits, and the ratio your acquirer watches

A first-time deposit (FTD) is a newly registered player funding an account for the first time, on a card your acquirer has never seen. Trusted deposits are the opposite end: repeat deposits from seasoned players whose cards, behaviour and dispute history the acquirer has already watched settle cleanly over weeks or months.

Your acquirer doesn't judge portfolio health by how many FTDs you generate. They judge it by the ratio of first-time to trusted deposits - how much of your volume is unproven fresh acquisition versus proven, seasoned traffic.

Two operators processing identical monthly volume can look completely different because of that mix:

 

	Traffic mix	How the acquirer reads it
Operator A	~70% trusted / ~30% FTD	Seasoned, stable - a book worth keeping
Operator B	~70% FTD / ~30% trusted	Unseasoned, high-monitoring - fragile

 

Same volume. Very different risk profile and often very different longevity.

Here's the tension underneath it: your acquisition team optimises for FTD volume; your acquirer optimises for the ratio. A campaign that floods the book with first-time deposits and no retention looks like growth to acquisition and like rising risk to underwriting. Same numbers, opposite readings. Almost everything else in this piece follows from that gap.

When does an FTD become "trusted"?

There's no universal standard here - ask ten processors and you'll get ten thresholds. But the shape is consistent, and it's worth being precise, because this is where most operators guess wrong.

A deposit doesn't graduate to "trusted" on the second transaction. It graduates when several things line up: the player's identity is fully KYC-verified, the first deposit has settled cleanly with no chargeback or fraud flag, authentication has succeeded (a clean 3-D Secure history helps), and the account has built a short record of legitimate behaviour -  a few deposits, ideally a withdrawal, over a number of days. Only then does the acquirer treat that card and player as seasoned.

So how does a processor even know a given transaction is a first-time deposit in the first place? It infers it from the signals it can see: whether KYC is complete, how many prior deposits and withdrawals the account has, and how long it's been since registration, combined with fraud-detection tooling and behavioural analytics. Different processors weigh these differently, which is exactly why the FTD/trusted line moves from one provider to the next.

The practical takeaway: "trusted" is earned per player, through verification and clean settlement, not granted by a deposit counter. Anything that moves legitimate players through KYC and a clean first settlement faster is what improves your ratio.

You don't get to label your own trusted traffic

Here's a mistake even experienced operators make: assuming they can tag their own users as "trusted" and route them accordingly.

You can send traffic flagged however you like. The acquirer's risk engine re-derives trust independently - from card-usage history, your merchant transaction history, device fingerprinting, behavioural patterns, card-network intelligence and authentication outcomes like 3-D Secure success. If the signals don't support "trusted", the label you attached means nothing.

This matters because it closes off a tempting shortcut. You can't improve your FTD-to-trusted ratio by relabelling - only by genuinely seasoning players: real KYC, clean settlement, returning behaviour, successful authentication. The ratio your acquirer acts on is the real one, not the one in your routing logic. 

The flip side is just as real: over-tighten to protect the ratio and you start false-declining good players, which is its own expensive problem - one of the payment challenges operators consistently raise.

Why acquirers read the FTD as the riskiest moment

Acquirers underwrite gambling as one of the highest-scrutiny categories the card schemes recognise - under the schemes' current integrity-risk programmes, gambling sits in the top tier alongside verticals like adult and dating, which means the acquirer sponsoring you carries registration and active-monitoring obligations of its own. Within that, the FTD is the sharpest edge, for three reasons.

No seasoning. Risk teams lean on history. A card that's deposited and played through cleanly for months is low-risk; a first-time deposit has none of that. It's the transaction most likely to be fraudulent - fraud attempts concentrate on first payments - and the one your acquirer can least defend if it goes wrong.

Chargeback concentration at the entry point. A legitimate player can dispute deposits they did in fact make, aka friendly fraud and a single high-frequency VIP repudiating months of transactions can generate hundreds of chargebacks. The schemes' current monitoring folds fraud and disputes into a single ratio, and chargebacks can count against that ratio even where you aren't liable for them. A cluster of disputed first-time deposits inflates the exact number your acquirer is measured on. Smaller and mid-sized operators feel this hardest: one bad cohort moves the ratio.

Negative-balance and pay-out exposure. Acquirers carry more negative-balance risk with gambling merchants than with ordinary retail - refunds, chargebacks and winnings pay-outs can flow out faster than wagers come in. If you're multi-acquired and switching traffic between banks, that exposure spreads, which is why reserves and pay-out controls appear in high-risk terms.

The uncomfortable truth, and the tension again: the exact levers that lift FTD conversion (fewer checks, more methods, instant clearing) are the ones that widen your acquirer's exposure on the least-seasoned transaction in the book.

An FTD isn't geo-neutral

The same first-time deposit behaves differently depending on where the player sits and this cuts both ways, conversion and risk.

On conversion, local methods and local acquiring lift first-deposit completion, because players fund through instruments they already trust. A card-only checkout that converts well in one market can stall in another where the default is a local bank transfer or wallet. Signup-to-deposit rates vary market to market for exactly this reason, which is why serious operators segment FTD by geo, device and method rather than reading one blended number.

On risk and approval, geo matters just as much and it's the half acquisition rarely sees. Route a deposit through an acquirer outside the player's region and the issuing bank sees a foreign acquirer BIN on a gambling MCC, and tightens. Cross-border deposits decline more often than domestic ones on the same card, and in some markets issuers soft-decline gaming-coded transactions almost by default - a player with funds and full intent, turned away on the MCC alone. Local acquiring in the corridor changes that: the transaction reads as domestic, approval improves, and the FTD you worked to win actually clears.

So the FTD you're optimising isn't one thing. An FTD in a market where you hold local acquiring and local methods is a genuinely different risk object from the same deposit forced cross-border through a foreign BIN - different approval odds, different decline behaviour, different dispute pattern downstream. iGaming has one of the most fragmented payments maps in high-risk: what unlocks one market won't touch the next.

This is where the question stops being "how do we lift FTD conversion?" and becomes "which acquirers are live for our MCC, in this market, right now?" - which is the question your payment partner should be answering before you submit, not after a wave of declines tells you the answer.

What if you're a brand-new iGaming site with no trusted traffic yet?

This is the question every new operator hits, and it's a fair one: if some acquirers are wary of FTD traffic, and all your traffic is FTD on day one, where does the first deposit come from?

You don't solve it by hiding the problem — you solve it by structuring around it until you've built a seasoned base. In practice, operators launching cold tend to do some combination of the following:

• Lead with rails that tolerate first deposits. Not every method carries the same first-deposit risk. Bank transfer, and vouchers like Paysafecard in markets where they're used and Bitcoin payment solutions are more tolerant of unseasoned traffic than a raw card FTD - useful for getting early deposits flowing while a card book seasons.
• Cap the first deposit, in amount and in count. A common pattern is a low FTD ceiling and a maximum number of deposits before the restriction lifts, so exposure on any single unseasoned player is bounded until they've proven out.
• Separate FTD and trusted flows. Some operators route first-time deposits through one processor and seasoned, trusted traffic through another. It feels counter-intuitive if you come from e-commerce, but it keeps unseasoned risk from contaminating the acquirer relationship that handles your proven book.
• Get players through KYC early. Since "trusted" is gated on verification and clean settlement, front-loading legitimate KYC is the fastest honest way to start converting FTDs into trusted traffic rather than sitting on a book that's 100% first-time.

None of this removes the cold-start reality - a new site is higher-risk to an acquirer, and pretending otherwise is how accounts get terminated. What it does is give the acquirer a structure they can say yes to: bounded exposure, clean coding, and a credible path from all-FTD to a healthy trusted ratio.

The conversion-vs-approval trade-off

This is the decision every iGaming operator is making, named or not — and it's where the acquisition-vs-acquirer tension becomes concrete:

Lever	Lifts FTD conversion	Raises acquirer risk / cost
Minimal KYC before first deposit	Yes - fewer drop-offs	Yes - weaker fraud signal, AML exposure, slower path to "trusted"
3-D Secure off / frictionless where allowed	Yes	Yes - liability shift lost, weaker authentication signal
Every payment method at first deposit	Yes	Mixed - some rails carry higher dispute rates
Instant deposit clearing	Yes - better UX	Yes - less time to screen
Acquisition push with no retention loop	FTD volume up	Yes - worsens the FTD-to-trusted ratio
Single acquirer, maximum approval push	Short-term yes	Yes - concentration, no redundancy

The goal isn't either extreme. Zero friction maximises conversion and, eventually, your chargeback ratio; maximum friction protects the ratio and kills the funnel. The operators who win read the middle deliberately - friction placed where it buys the most risk reduction per point of conversion lost, retention that seasons FTDs into trusted deposits, and routing that puts each first deposit in front of the acquirer most likely to approve and hold it.

What a clean FTD flow looks like and what to expect from an iGaming payment provider

The difference between a deposit flow your acquirer trusts and one they throttle usually comes down to a handful of things. It's also a fair checklist for judging any iGaming payment provider or gambling payment processing partner:

• Risk data at the deposit, not after it. Device, IP, velocity and payment-source signals cross-checked at the point of first deposit - the same behavioural data a well-run operator already collects - so a suspect FTD is stepped up rather than blanket-blocked.
• Correct MCC and descriptor from day one. Miscoding a gambling deposit to dodge scrutiny is the fastest route to a terminated account. Clean coding is what lets an acquirer defend you.
• A retention loop that improves the ratio. Everything that turns a first-time depositor into a returning, seasoned one moves your FTD-to-trusted ratio the way underwriting wants it to move. That starts at the deposit itself — the approval rates, local methods and routing that decide whether a first deposit even succeeds. (This is its own discipline; our iGaming deposit solutions guide covers the conversion side in depth.) This is a payments concern, not just a marketing one.
• Redundancy under the FTD. Two or more acquirers per book means a declined or throttled first deposit has somewhere to route, and no single bank carries all your entry-point risk. Running 2+ acquirers per merchant is standard practice for exactly this reason — and it matters most under load, when a peak-event surge of first-time deposits can trip a single acquirer's risk limits overnight.
• Reserves and pay-out controls you've actually modelled. If you know your negative-balance exposure and can show controls around it, that's a conversation with your acquirer rather than a surprise.
• A defence file for friendly fraud. Compelling-evidence data - login, wager, device history tying the cardholder to the deposit - turns disputable FTDs into winnable ones.

None of these are "add more friction". They're "make the FTD legible to the people underwriting it and season it into trusted traffic as fast as you can".

How CatalystPay helps

The FTD sits exactly where acquisition and risk collide and that's the seam we work in.

We're not a plug-and-play PSP. We act as an extension of your payments team, placing and optimising card processing across 30+ regulated acquirers, and we know which of them are live for iGaming in your target markets before you submit. For a deposit flow, that means routing built for approval and seasoning, redundancy so no single acquirer owns all your entry-point risk, and correct coding from day one so your FTDs are defensible rather than disguised.

Whether you're seasoning an established book or launching cold with no trusted traffic yet, the structure is what an acquirer says yes to - bounded FTD exposure, clean coding, and a credible path to a healthy trusted ratio.

We won't promise approvals or a chargeback number no one can stand behind. What we will do is look at your actual deposit flow, geos and methods and your FTD-to-trusted mix and tell you where it's likely to stall under underwriting, and how we'd structure it so your fastest funnel is also your most defensible one.

If your FTD conversion is strong but your acquirer relationships feel fragile, that's a conversation worth having.