Open Letter: Visa / Tink / PayOp — Offshore Casino “Pay-by-Bank” Has Become a Default Rail. Who Carries the Risk?

Executive Summary

Recent Rail Atlas assessments of the FGS Software Solutions casino ecosystem — including Monixbet, Rakoo Casino, and VoltSlot — reveal a highly repeatable deposit architecture. What is presented to users as “Pay by Bank / Open Banking” appears to follow a standardized chain: PayOp → Tink (a Visa subsidiary) → Revolut OBA, with payments frequently attributed to FairGame G.P. N.V. as the receiving entity.

This no longer looks like a one-off configuration. It resembles an established operational rail. The unresolved issue is not only legality by jurisdiction, but accountability: who performs which compliance checks, at which layer, and why this setup continues to operate at scale.

Key Findings

• A consistent open-banking flow was observed:
  PayOp checkout → Tink redirect (link.tink.com) → Revolut OBA consent (oba.revolut.com) → payment credited to FairGame G.P. N.V.
• The casinos involved are offshore brands that appear optimized for EU users while keeping the merchant identity opaque at the banking layer, often via payment-agent entities.
• In PSD2-style models, banks typically authorize the TPP (Tink) rather than the downstream merchant, making TPP onboarding and oversight the critical compliance choke point.
• Additional “instant bank transfer” rails were observed that may convert deposits into USDC via crypto paths (e.g., Rillpay → Kryptonim), alongside a separate “instant banking” corridor associated with Contiant through an opaque gateway domain (paymentproccesing.net).
• Taken together, these rails suggest deliberate multi-rail obfuscation rather than isolated payment experimentation.

Contextual Narrative

For months, Scam-Or Project has been mapping payment chokepoints used by offshore casino networks. What now stands out is the simplicity of the model: open banking has become the cleanest and most resilient deposit rail for operators that would otherwise struggle to maintain card acceptance under standard scheme scrutiny.

Within the FGS ecosystem, the user experience labeled as “bank transfer” is not a direct transfer at all. It is a layered consent and initiation pipeline:

1. PayOp operates as the front-end payment option.
2. Tink functions as the open-banking initiation layer.
3. Revolut OBA is used to authorize Tink AB as the third-party provider.
4. The beneficiary is often listed as FairGame G.P. N.V., indicating a centralized payment-agent structure.

This stacking of responsibilities creates precisely the environment where risk can fall between institutional boundaries.

This letter is addressed to those boundaries.

Open Letter to Compliance Teams

(Visa, Tink, PayOp, Revolut OBA, and Partner Banks)

To the compliance, AML, and financial-crime units of Visa, Tink, PayOp, Revolut, and affiliated banking partners:

This publication is an evidence-based compliance challenge, not a verdict. We are not asking for trust — we are asking for answers to questions that the industry has postponed while this pattern has become normalized.

What Was Observed in the FGS Cluster

Across multiple offshore casino brands under the same operational umbrella (Monixbet, Rakoo Casino, VoltSlot), we documented deposit paths where:

• Players select PayOp or a bank-transfer-styled option in the casino cashier.
• Users are redirected to Tink (link.tink.com), with messaging indicating that Tink processes the payment.
• Users then reach Revolut OBA (oba.revolut.com) to authorize Tink AB.
• In several flows, FairGame G.P. N.V. is shown as the payment recipient, consistent with a payment-agent model.
• Parallel rails (crypto conversions and opaque gateway domains) run alongside this setup, pointing to a designed redundancy strategy.

The Central Compliance Question

How can an open-banking provider owned by Visa integrate a PSP such as PayOp in a way that effectively enables offshore casino deposits from EU retail bank accounts — while the downstream merchant identity and local legality remain indistinct?

If the response is “we only onboard PayOp”, the follow-up is unavoidable:
What exactly is PayOp required to enforce, how is that verified, and what happens when those controls fail?

Extended Analysis: Why This Structure Persists

1. Banks Authorize the TPP, Not the Merchant

In open-banking flows, the bank interface focuses on approving the third-party provider (here, Tink AB). The merchant brand may never surface in a way that triggers meaningful risk classification, especially when a payment-agent entity is listed as payee.

Outcome: Merchant legality is not resolved at the bank layer.

2. PSP-Centric Onboarding Creates a Compliance Handoff

If Tink’s direct counterparty is PayOp, downstream casinos may be treated as sub-merchants:

• Tink screens PayOp.
• PayOp screens its merchants.
• Casinos operate behind a payment-agent name.
• Banks see a corporate recipient.

Outcome: Responsibility is fragmented; oversight is diluted.

3. Standard Monitoring Rarely Flags “Offshore Casino”

Sanctions and transaction-monitoring systems are not designed to reliably flag “casino marketed into NL or BE without local authorization”, particularly when:

• The payee is a generic corporate entity.
• Descriptors are neutral.
• No sanctions nexus exists.

Outcome: Activity appears routine until a targeted review occurs.

4. Commercial Incentives and Weak Escalation Loops

Pay-by-bank is cheaper, scales efficiently, and avoids chargeback pressure. Where policies are ambiguous, transaction volume tends to override caution — until regulators or partner banks intervene.

Outcome: The system drifts toward permissiveness by default.

Questions That Require Clear Answers

A) Merchant-of-Record and Accountability

• Who is the merchant of record: PayOp, FairGame G.P. N.V., or the casino brand?
• Who ensures jurisdictional legality (e.g., NL/BE marketing rules, licensing)?
• Where is merchant identity logged (TPP IDs, client_id, redirect URLs, payee mappings), and who can audit it?

B) Sub-Merchant Onboarding and Oversight

• Does Tink require PayOp to submit full KYB/UBO documentation for high-risk sub-merchants?
• Is any independent verification or enhanced due diligence performed?
• What events trigger termination — regulatory inquiries, adverse media, restricted-geo traffic, repeated complaints?

C) Monitoring, Geography, and Legality Controls

• What monitoring detects EU retail-bank concentration into offshore casino payment agents?
• Are geo-controls enforceable and audited?
• How are transactions treated when the payee is a payment agent rather than the branded merchant?

D) Visa Group Governance

• What group-level standards govern Visa-owned open-banking rails used in iGaming contexts?
• Are high-risk PSP integrations subject to centralized review and periodic reassessment?

Actionable Insight

Open banking is now a primary deposit rail for offshore gambling ecosystems. If accountability remains undefined, regulators will define it — most likely through enforcement actions that redraw the boundaries of what embedded open banking is permitted to do in high-risk verticals.

Any participant in this stack should be able to state, immediately and in writing:

• Who is the merchant of record?
• Who approves and monitors sub-merchants?
• What evidence proves geo-restrictions and legality controls are enforced?
• What systems detect payment-agent obfuscation?

Call for Information

If you work at Visa, Tink, PayOp, Revolut, a partner bank, or within the FGS / FairGame payment chain — and have access to onboarding policies, sub-merchant agreements, KYB/UBO files, internal risk assessments, monitoring rules, escalation records, regulator correspondence, or settlement descriptors linked to these flows — submit documentation securely via the Scam-Or Project whistleblower section.

Please redact personal data and focus on contractual terms, process documentation, and transaction metadata.