FinTelegram’s Rail Atlas review of the FGS Software Solutions casino cluster (Monixbet, Rakoo Casino, VoltSlot) shows a repeatable deposit architecture: (1) “instant bank transfer” flows that appear to convert deposits into USDC via a crypto rail (Rillpay), (2) an open-banking stack where PayOp routes players into Visa-owned Tink and onward to Revolut’s open-banking interface, and (3) an alternative “instant banking” path using Contiant and a misspelled gateway domain (paymentproccesing.net), plus MiFinity deposits settling to FairGame G.P. N.V. as payment recipient.
Key Facts (Observed + Corroborated)
- Same rail pattern across multiple casinos: Monixbet, Rakoo Casino, and VoltSlot present largely identical cashier options (bank + crypto + “instant” variants).
- Payment recipient surfaced in flows: Screenshots show deposits directed to FairGame G.P. N.V. (Curaçao) as the receiving party in at least some rails (MiFinity; PayOp/Tink flow wording).
- Open-banking rail chain: PayOp → Tink (via
link.tink.com) → Revolut OBA (oba.revolut.com) → payment to FairGame G.P. N.V. - Contiant appears in the same ecosystem: A misspelled gateway domain
paymentproccesing.netappears in cashier flow, and Similarweb signals show monixbet.com among the referring sites topaywith.contiant.com(small but present). - PayOp ↔ iGaming positioning: PayOp markets iGaming payment services and its documentation/terms reference its operating entity.
- Tink is a Visa-owned open-banking provider (Visa completed acquisition) and markets payment-initiation/open-banking capabilities, including iGaming use-cases.
Rail Map Snapshot (How the Money Moves)
1) “Instant Bank Transfer” that behaves like a crypto on-ramp
Player selects: “Direct Bank Transfer / Instant Bank Transfer” (casino cashier label)
Observed stack (from our testing notes + cashier UI):
Rillpay → USDC → casino wallet(s)
Why it matters: This is a pattern we see repeatedly in offshore casino environments: a bank-transfer UI that is operationally fulfilled by a crypto purchase (stablecoins), reducing traditional card/acquirer visibility and potentially shifting AML/KYC responsibilities onto the crypto leg.
2) Open Banking rail: PayOp → Tink → Revolut OBA → FairGame G.P. N.V.
Player selects: PayOp in cashier
Observed flow (screenshots):
- PayOp modal routes user into Tink (
link.tink.com) and explicitly states that FairGame G.P. N.V. uses Tink to process the payment. - User is then redirected to Revolut’s open banking authorization page (
oba.revolut.com) showing “Authorize Tink AB.”
Interpretation: This is consistent with a PIS/AIS-style account-to-account payment initiation flow where Tink acts as the open-banking layer and Revolut’s OBA is the bank-side consent/auth step.
Tink context: Visa completed the acquisition of Tink, and Tink markets open-banking payment initiation (including iGaming-related use cases).
PayOp context: PayOp’s own materials position it in high-risk/iGaming processing, and its terms identify the operator entity.
3) Contiant rail via misspelled gateway domain: Monixbet → paymentproccesing.net → (Contiant / Bank selection / Revolut OBA)
Player selects: “Instant Bank Transfers” (casino cashier label)
Observed indicators:
- The browser status bar shows requests to
paymentproccesing.net(note the double “cc”), suggesting an intermediary deposit page/gateway. - Similarweb signals show monixbet.com appears among referrers to
paywith.contiant.com(small share), linking this casino into the same Contiant gateway ecosystem you previously mapped. - Your prior Contiant work established Contiant as a “technical” pay-by-bank layer in front of regulated open-banking rails, with a notable Benelux footprint.
Contiant context: Contiant’s own merchant documentation identifies the company as a Bulgarian entity and describes AIS/PIS technical services positioning.
4) MiFinity rail: Monixbet → paymentproccesing.net → MiFinity → FairGame G.P. N.V.
Observed (screenshots):
- A MiFinity-branded deposit page hosted at
paymentproccesing.netshows “Deposit to FairGame G.P. N.V.” and the MiFinity support email contact. - MiFinity context: MiFinity states it is dual-licensed (UK FCA + Malta MFSA) and its legal terms identify MiFinity UK Limited as an FCA-authorised EMI (Register Ref. 900090).
Who is the “Payment Agent” here? (FairGame G.P. N.V.)
Our testing indicates that FairGame G.P. N.V. (Curaçao) appears as the named recipient/payment agent in multiple deposit rails (PayOp/Tink flow wording; MiFinity deposit page). That is a key compliance signal: it suggests consolidation of player funds at a central entity that may sit between the casino brand and upstream PSP/open-banking providers.
Verification targets:
- bank beneficiary details (IBAN/BIC), merchant IDs, PayOp/Tink “client_id” mappings, and settlement statements showing where funds land and under what descriptor.
Why This Matters (Compliance Lens)
- Benelux exposure + open-banking chokepoints
Our earlier Contiant traffic intelligence suggested a strong Netherlands/Belgium banking footprint. If these rails are used to fund offshore casinos that appear to be offered into NL/BE without local authorisation, that is a high-sensitivity corridor for regulators and banks. - Open-banking providers can become the “quiet rail” for high-risk merchants
Even where the open-banking layer is regulated (e.g., Tink as a payment institution and MiFinity as an EMI), risk concentrates at the edges: merchant onboarding, MoR identification, and monitoring of downstream brand networks and affiliate funnels. - Gateway opacity is a recurring red-flag pattern
The use of thin, sometimes oddly named domains (e.g.,paymentproccesing.net) as cashier gateways complicates consumer recognition, dispute handling, and third-party monitoring. It also raises questions about who controls the payment page and what scripts/vendors are embedded.
Call for Information (Whistle42)
If you have direct evidence about these rails—PayOp/Tink onboarding records, merchant contracts, settlement statements, MoR documentation, bank beneficiary details, gateway operator identity for paymentproccesing.net, or correspondence with compliance teams—please submit it via Whistle42.com. We are specifically looking for: (1) PayOp account/merchant IDs, (2) Tink client_id mappings and service agreements, (3) bank transfer descriptors and beneficiary IBANs, (4) proof of who controls the cashier gateway domains, and (5) any regulator notices, chargeback/dispute logs, or account closures linked to these flows.
