Open Letter: Visa/ Tink/PayOp — The Offshore Casino “Pay-by-Bank” Pattern Is Now a Standard Rail. Who Owns the Risk?

In recent Rail Atlas reviews of the FGS Software Solutions casino cluster (including Monixbet, Rakoo Casino, and VoltSlot), we documented repeatable deposit flows where “Pay by Bank / Open Banking” rails appear to route through PayOp → Tink (Visa subsidiary) → Revolut OBA, with deposits attributed to FairGame G.P. N.V. as the receiving party. This looks less like an anomaly and more like a normalized pattern. Compliance teams should explain—clearly—who screens what, and why this is allowed to run.

Key Points

• Our observations indicate a consistent open-banking chain: PayOp checkout → Tink redirect (link.tink.com) → Revolut OBA consent (oba.revolut.com) → payment attributed to FairGame G.P. N.V. (as shown in deposit flows).
• “Illegality” is jurisdiction-dependent, but the risk question is not: these are offshore casino brands that appear engineered to serve EU users while keeping the merchant identity at the bank layer ambiguous (often via payment-agent entities).
• In PSD2-style flows, banks typically authorize the TPP (Tink), not the downstream merchant. That design makes the TPP’s onboarding and monitoring controls the decisive compliance chokepoint.
• We also observed additional “instant bank transfer” rails that may effectively convert deposits into USDC via crypto pathways (e.g., Rillpay → Kryptonim), and a separate “instant banking” corridor linked to Contiant via an opaque gateway domain (paymentproccesing.net), underscoring a broader multi-rail obfuscation pattern.

Read our report on the FairGame Payment Rails here.

Short Narrative

FinTelegram has been mapping payment chokepoints around offshore casinos for months. What we are seeing now is uncomfortable in its simplicity: open banking has become the cleanest deposit rail for merchants that would struggle to sustain card acceptance under normal scheme scrutiny.

In the FGS cluster, the “bank transfer” experience presented to players is not a simple bank transfer. It is a structured consent-and-initiation pipeline: PayOp acts as the front-end payment option; Tink appears as the open-banking layer; and Revolut’s OBA interface is invoked to authorize Tink as the third-party provider. The payment recipient is presented as FairGame G.P. N.V., suggesting a central payment agent structure. This is exactly the kind of stacked accountability that allows risk to “fall between chairs.”

This letter is addressed to those chairs.

Open Letter to Compliance (Visa, Tink, PayOp, Revolut OBA, and Partner Banks)

To the Compliance and Financial Crime teams of Visa, Tink, PayOp, Revolut, and partner financial institutions:

We are publishing this as an evidence-led compliance challenge, not as a verdict. We do not ask you to “take our word for it.” We ask you to answer the questions that the industry has been avoiding—because this pattern is no longer exceptional.

What we observed (FGS cluster)

Across multiple offshore casino brands in the same operator family (Monixbet, Rakoo Casino, VoltSlot), we documented deposit journeys where:

1. The user selects PayOp or a bank-transfer-like option in the casino cashier.
2. The user is routed to Tink (link.tink.com) with language indicating the payment is processed through Tink.
3. The user is then redirected to Revolut OBA (oba.revolut.com) to authorize Tink AB.
4. In at least some flows, the payment is attributed to FairGame G.P. N.V. as the receiving party (payment agent pattern).

We also documented parallel rails (crypto conversions and opaque gateway domains), which suggests an intentional multi-rail resilience strategy.

The core compliance question

How can a Visa-owned open-banking provider (Tink) integrate a PSP (PayOp) in a way that appears to enable offshore casino deposits into EU consumer bank accounts—while the downstream merchant and local-legality context remain blurred?

If your answer is “because we only onboard PayOp,” then the next question is: what exactly do you require PayOp to do, how do you verify it, and what do you do when it fails?

Extended Analysis: Why This Can Run Even if “Everyone Should Know”

1) The bank authorizes the TPP, not the merchant

In open-banking flows, the bank’s interface is focused on authorizing the third-party provider (here: Tink AB) to initiate a payment or access account information. The bank may not see a merchant brand in a way that triggers meaningful risk classification—especially when a payment agent entity sits as the payee.

Result: The bank layer is not where merchant legality gets solved.

2) The onboarding perimeter is often the PSP, not the casino

If Tink’s direct customer is PayOp, then downstream casinos may be treated as sub-merchants. That can create a compliance “handoff”:

• Tink screens PayOp.
• PayOp screens its merchants.
• The casino operates behind a payment agent name.
• The bank sees a payment to a corporate payee.

Result: Everyone has a piece of the puzzle; nobody holds the whole picture.

3) “Transaction screening” may not catch “offshore casino”

Sanctions screening and typical transaction monitoring do not reliably flag “casino marketed into NL/BE without local authorization,” especially when:

• the payee is a corporate payment agent,
• descriptors are generic,
• and there’s no sanctions nexus.

Result: The activity can look “normal” to automated systems—until a targeted investigation occurs.

4) Commercial incentives + weak escalation loops

Pay-by-bank is cheaper, has fewer chargeback dynamics, and scales. If policy and controls are ambiguous, volume wins—until a regulator, partner bank, or reputational event forces a change.

Result: The system drifts toward permissiveness.

The Questions You Need to Answer (Publicly, if possible)

A) Merchant-of-record and responsibility

1. Who is the merchant of record for these transactions—PayOp, FairGame G.P. N.V., or the casino brand?
2. Who is responsible for ensuring the merchant’s jurisdictional legality (e.g., NL/BE marketing restrictions, licensing requirements)?
3. Where, precisely, is the “merchant identity” stored in logs (TPP ID, client_id, redirect URL, payee mapping), and who can audit it?

B) Sub-merchant onboarding and oversight

1. Does Tink require PayOp to provide full KYB/UBO files for sub-merchants in high-risk verticals?
2. Does Tink independently verify a sample of sub-merchants (enhanced due diligence), or rely entirely on PayOp’s representations?
3. What are the termination triggers? (e.g., regulator inquiries, adverse media, traffic from restricted geos, repeated complaints)

C) Monitoring and geo/legality controls

1. What monitoring detects EU retail-banking concentration into offshore casino payment agents?
2. Are there enforceable geo-controls (blocked countries, residency checks) and are they audited?
3. How do you treat flows where the payee is a payment agent rather than the branded merchant?

D) Visa group governance (because Tink is in the Visa family)

1. What group-level standards apply to Visa-owned open-banking rails used in iGaming corridors?
2. Are high-risk PSP integrations (like PayOp-type iGaming processors) subject to group-level review and periodic reassessment?

Actionable Insight

This is the compliance truth: open banking is now a primary deposit rail for offshore gambling ecosystems. If the industry doesn’t clarify accountability, regulators will clarify it for you—likely through enforcement that redefines what “embedded open banking” can do in high-risk verticals.

If you operate any layer of this stack, you should be able to answer—immediately and in writing:

• Who is the merchant of record?
• Who screens and approves sub-merchants?
• What evidence proves geo/legality controls are enforced?
• What monitoring detects payment-agent obfuscation?

Call for Information (Whistle42)

If you work at Visa, Tink, PayOp, Revolut, a partner bank, or within the FGS/“FairGame” payment chain—and you have onboarding policies, sub-merchant agreements, KYB/UBO requirements, risk memos, monitoring rules, escalation tickets, regulator correspondence, or settlement descriptors tied to these flows—submit evidence securely via Whistle42.com. Redact personal data; focus on contracts, process documents, and transaction metadata.