A processor pitch has probably told you open banking is the clean way around card declines for your iGaming platform — no issuer blocking a deposit at the network level, no rolling reserve eating into settlement. Before you build a roadmap around that pitch, you need to hear the part it usually leaves out.
This is the one area of open banking where the honest answer runs against the sales narrative. Banks are actively building tools that block gambling transactions across open banking rails specifically, and a meaningful share of PISPs decline to onboard iGaming merchants at all. Both frictions are real, current, and vertical-specific — not a hypothetical edge case buried in an appendix.
This guide sets out exactly where that friction sits, where open banking genuinely does work for an iGaming operator today, and why a licensed EMI or PI payment agent relationship — covered in our guide to Cyprus payment agents — remains the more established route for this vertical specifically.
Direct Answer
Open banking is not a frictionless payment alternative for gambling. Some banks now let customers block gambling-related transactions across open banking rails specifically, and many PISPs decline to onboard iGaming merchants outright over compliance exposure. AISP-based affordability and identity checks work well for iGaming; PISP-based deposit rails carry real, partial, provider-dependent friction.
Why Are iGaming Operators Looking at Open Banking Payments at All?
The appeal is genuine. Card-based deposits for iGaming run into issuer-level declines that have nothing to do with a customer's actual balance, MCC-based blocks some card issuers apply to gambling merchant categories outright, and the same rolling reserve and chargeback ratio exposure that follows every high-risk vertical. A payment initiated through a PISP — the license category PSD2 created for open banking payment initiation — moves directly between bank accounts and, in principle, sidesteps all of it.
That principle is real. What operators tend to skip past is that the two frictions covered in the next two sections are specific to gambling in a way they are not to crypto, forex, or most other high-risk verticals.
What to Consider:
- Card-level blocking is real: issuer-level declines on gambling MCCs happen independent of a customer's available balance or credit standing.
- PISP rails bypass the card network: in principle, an A2A payment removes the issuer decline and the rolling reserve that come with card processing.
- The appeal is vertical-agnostic: crypto and forex operators chase the same cost and friction reduction, but iGaming faces additional friction they largely do not.
- A working alternative already exists: licensed EMI and PI payment agent relationships are a mature route for this vertical, not a fallback.
Example
An online sportsbook saw roughly 9% of card deposit attempts decline at the issuer level over a single quarter, unrelated to customer balance. It piloted a PISP-based deposit option to recover that volume before discovering that only two of the five PISPs it approached would onboard a gambling merchant at all.
Final Takeaway: Treat the card-decline problem and the payment-rail solution as two separate questions — confirm a PISP will actually take on an iGaming merchant before building a roadmap around the fee saving.
What Is the Real Friction? Banks Actively Blocking Gambling Use of Open Banking Rails
Some UK banks have let customers block card-based gambling transactions for several years, a voluntary feature offered by the bank itself rather than a specific rule from the UK Gambling Commission. What is less widely discussed is that certain banks have extended that same blocking capability to open banking rails specifically, since around 2021, closing a loophole where a customer could top up an e-wallet or gambling account through an open-banking transfer after their card was already blocked.
Coverage is partial and provider-dependent, not universal — not every bank offers the feature, and not every open-banking provider integrates with it consistently. But where it exists, it applies at the customer's own request, meaning a self-excluded or blocking customer's PISP-initiated deposit can simply fail at the bank's end, with no visibility into why from the merchant side.
Reality Check
Open banking is frequently sold to iGaming operators as a frictionless alternative to card rails. It is the opposite of frictionless for this specific vertical. Some banks now let customers block gambling-related transactions across open banking rails, extending a control that started with card payments specifically to close the open-banking loophole. Coverage is partial and provider-dependent, not universal, but it is real, current friction that a card-decline workaround does not actually solve — it just moves the block one step downstream.
What to Consider:
- The block sits at the customer's bank, not your provider: a declined PISP payment for this reason gives the merchant no error detail distinguishing it from any other failure.
- Coverage is not universal: confirm which banks and which open-banking providers actually support gambling-blocking before assuming the friction applies to your entire customer base.
- This closes a known loophole: the blocking extension exists specifically because customers were bypassing card-level gambling blocks through open banking top-ups.
- It is bank policy, not UKGC rule: the UK Gambling Commission has not issued a specific rule on open-banking gambling blocks — this is a bank- and provider-level control, not a regulatory mandate.
Example
A licensed sportsbook's PISP-based deposit option failed silently for roughly 6% of attempted transactions in its first month live. Investigation traced the failures to customers who had activated gambling-transaction blocks with their own banks — a friction the operator had not modeled because its card-decline data gave no indication it existed on the open-banking side too.
Final Takeaway: Model gambling-transaction blocking as a real, current failure mode for PISP-based deposits, not an edge case — it will not show up in your data until customers who have activated it start failing silently.
Why Do Many PISPs Decline to Onboard iGaming Merchants at All?
The second friction sits earlier in the process: a meaningful share of payment-initiation providers decline to onboard iGaming merchants in the first place, independent of the bank-blocking issue above. This is widely reported as industry-side friction rather than a documented regulatory statistic, and it comes down to compliance exposure a PISP has to carry once it takes on a gambling merchant.
Age verification, AML monitoring calibrated to gambling-specific typologies, and the licensing exposure of processing for a regulated-but-high-risk vertical all add cost and review burden a smaller PISP may not want to carry, particularly when its core business is retail bill payments or e-commerce checkout, not high-risk merchant acquiring.
What to Consider:
- Ask directly, in writing: get explicit confirmation that a PISP's risk appetite covers licensed iGaming operators before any integration work begins.
- Smaller PISPs decline more often: providers built around retail bill-pay or general e-commerce checkout typically lack the compliance infrastructure to carry gambling risk.
- This is a business decision, not a legal bar: a licensed iGaming operator is not prohibited from using open banking rails — providers are simply choosing not to carry the compliance cost.
- Expect a smaller shortlist than for other verticals: crypto and forex operators typically find more PISP options willing to onboard than iGaming operators do.
Example
An operator licensed in a reputable EU jurisdiction contacted six PISPs to add a pay-by-bank deposit option. Four declined during initial screening once the merchant category was disclosed as gambling, one required a six-month track record before reconsidering, and one agreed to onboard subject to enhanced ongoing monitoring.
Final Takeaway: Budget for a short PISP shortlist and a longer sales cycle than other high-risk verticals see, and confirm gambling-specific risk appetite before any integration spend.
Where Does Open Banking Actually Work Today for iGaming?
The picture is not universally bleak — AISP access, the read-only side of open banking covered in full in our open banking for high-risk businesses guide, largely avoids both frictions above because it never initiates a payment. That makes it genuinely useful for exactly the checks a licensed iGaming operator already has to run: affordability assessment and source-of-funds verification for at-risk customers, and stronger KYC evidence at onboarding.
Operators building for the UK market specifically should track this against their existing license conditions on customer-affordability checks, rather than treating AISP access as a new obligation — it is a better data source for a check most licensed operators already have to perform.
What to Consider:
- AISP for affordability checks: consented account data gives a faster, more accurate affordability picture than a self-reported income figure.
- AISP for source-of-funds evidence: transaction history strengthens the AML file for high-value depositors without adding a payment-rail dependency.
- PISP works best where blocking friction is lowest: jurisdictions or customer segments without the UK-style gambling-block feature see fewer silent deposit failures.
- Treat PISP deposits as a pilot, not a primary rail: run it alongside card and EMI processing while you measure real completion and failure rates.
Example
A licensed operator used AISP-sourced account data to automate affordability reviews for customers crossing an internal deposit threshold, cutting manual review time from roughly 45 minutes to under 10 minutes per case, while keeping card and EMI rails as the only live deposit mechanisms.
Final Takeaway: Deploy AISP access first for affordability and source-of-funds evidence — it is where open banking's value for iGaming is least contested — and treat PISP deposit rails as a slower, narrower pilot.
| Open banking use case | iGaming suitability today | Why |
|---|---|---|
| AISP — affordability checks | Strong | Read-only; avoids both blocking and onboarding friction |
| AISP — source-of-funds / KYC | Strong | Strengthens AML file without touching a payment rail |
| PISP — deposit rail (UK customers) | Weak to moderate | Bank-side gambling blocks fail transactions silently |
| PISP — deposit rail (non-UK customers) | Moderate | Fewer bank-side blocks reported, but PISP onboarding still limited |
| PISP — withdrawal / payout rail | Limited | Fewer providers support payout use cases at all |
What's the More Established Alternative for iGaming Payment Structuring?
A licensed EMI or PI payment agent relationship, structured properly, remains the more established route for iGaming payment processing specifically. Our guide to Cyprus payment agents covers how these relationships work under supervision — verified license status, segregated safeguarding of client funds, and continuous AML/KYC obligations — and how to tell a properly licensed agent from a shell dressed up as one.
The comparison is not close to even on maturity. Payment agent structures for iGaming have years of operating history, established dispute-handling processes, and a track record acquirers and regulators both recognize. Open banking for this specific vertical is, honestly, still working through the two frictions covered above.
What to Consider:
- Maturity favors the payment agent route: EMI/PI structures for iGaming have a longer track record than open banking rails do for this vertical specifically.
- Verify license status independently: the same public-register verification that applies to any payment agent applies here — do not take a certificate at face value.
- Use open banking to complement, not replace: AISP checks strengthen the compliance file that supports a strong payment agent relationship; they are not a substitute for one.
- Sequence the decision: secure the primary payment agent relationship first, then layer AISP-based verification and a cautious PISP pilot on top.
Example
An iGaming operator secured a licensed Cyprus payment agent relationship as its primary EUR processing rail, added AISP-based affordability checks to strengthen its compliance file, and piloted a PISP deposit option only for non-UK customer segments where bank-side blocking was less prevalent — keeping the mature rail primary and the newer one supplementary.
Final Takeaway: Keep a licensed EMI or PI payment agent relationship as the primary iGaming payment rail, and treat open banking as a compliance-strengthening and narrow-pilot addition until the vertical-specific friction eases.
| Feature | Licensed EMI/PI payment agent | Open banking (PISP) |
|---|---|---|
| Track record for iGaming | Established, multi-year | Early, still maturing |
| Onboarding acceptance rate for gambling | Higher — sector-experienced agents exist | Lower — many providers decline outright |
| Bank-side transaction blocking risk | Not applicable | Real, for UK-linked customers specifically |
| Fund safeguarding | Segregated accounts or insurance, supervised | Varies by provider, less standardized |
| Dispute handling | Established process via agent/acquirer | Provider's own process, no chargeback equivalent |
Getting the iGaming Payment Decision Right
The discipline here is refusing to let a genuinely appealing pitch override two frictions that are specific to this vertical and well documented once you look past the marketing: bank-side gambling blocks on open banking rails, and a meaningful share of PISPs declining to onboard iGaming merchants at all.
Neither friction makes open banking useless for an iGaming operator. AISP access genuinely strengthens affordability and source-of-funds evidence, and a cautious PISP pilot can add incremental deposit volume in the right customer segments — the fee-versus-adoption math from our pay by bank vs. cards comparison still applies to any volume that does convert. What it should not do is replace a licensed EMI or PI payment agent relationship as the primary rail.
Sequence it: keep the established payment agent relationship primary, add AISP-based verification to strengthen your compliance file, and pilot PISP deposits narrowly, with the bank-blocking and onboarding friction modeled in from day one rather than discovered after launch.
How BankMyCapital Helps
Structuring iGaming payment processing around this reality means keeping a licensed EMI or PI payment agent relationship as the core rail, confirming any PISP's actual gambling risk appetite before integration, and using AISP data to strengthen the compliance file that underpins the whole structure. BankMyCapital sequences it in that order rather than presenting open banking as a drop-in replacement for established processing.
See our payment processing services for how EMI, PI, and open banking rails are structured together for iGaming operators.
Frequently Asked Questions
Do banks actually block gambling payments made through open banking?
Some do. Certain banks have extended their existing card-based gambling-blocking feature to cover open banking transfers as well, at the customer's own request, closing a loophole where blocked customers topped up through open-banking rails instead. Coverage is partial and provider-dependent, not universal.
Why do payment providers refuse to work with iGaming operators on open banking rails?
Many PISPs decline gambling merchants over compliance exposure — age verification, gambling-specific AML monitoring, and licensing review all add cost a provider built for retail or e-commerce use cases may not want to carry. This is a business decision by the provider, not a legal prohibition on licensed operators using the rail.
Does open banking work at all for iGaming compliance?
Yes, on the AISP side specifically. Read-only account data strengthens affordability checks and source-of-funds evidence without touching a payment rail, avoiding both the bank-blocking and PISP-onboarding frictions that affect deposit-side use cases.
Should an iGaming operator replace its payment agent relationship with open banking?
No. A licensed EMI or PI payment agent relationship remains the more established route for iGaming payment processing. Open banking works best as a compliance-strengthening addition and a narrow, carefully monitored deposit pilot, not a primary-rail replacement.
What does BankMyCapital charge for iGaming payment structuring?
Engagements are scoped individually because jurisdiction, license status, and existing rail mix all change the workload, but structured payment support starts from a fixed floor rather than a percentage of turnover. Ask for a scoped quote once you can describe your license and current processing setup.