The institutionalization of the digital asset economy within the European Union has reached a definitive stage. As the financial sector navigates the complexities of the mid-2020s, regulatory compliance and operational excellence are no longer optional for businesses seeking to leverage blockchain-based financial rails.

For crypto payment gateways based in the EU, such as INXY Payments, the verification workflow represents the first and most critical touchpoint in establishing a secure, bank-grade relationship with professional partners. This report provides an exhaustive analysis of the merchant verification process, grounded in the primary directives of the Markets in Crypto-Assets (MiCA) Regulation and the practical requirements of the Know Your Business (KYB) standards.

The Regulatory Landscape: MiCA, TFR, and DAC8

The "Regulatory Rubicon" has been crossed, shifting the focus of European authorities from drafting policy to aggressive enforcement. Central to this environment is the Markets in Crypto-Assets Regulation (MiCA), which has successfully harmonized the rules for digital assets across all 27 EU member states.

The verification process is now governed by three key frameworks:

1. MiCA Authorization: Eliminates the "Wild West" era, ensuring only fully authorized providers operate within the EEA.
2. Transfer of Funds Regulation (TFR): Enforces a "Zero Threshold" policy for the "Travel Rule," requiring detailed data on the originator and beneficiary for every transaction.
3. DAC8: Mandates strict tax reporting and the collection of Tax Identification Numbers (TINs) to ensure fiscal transparency.

Architecture of the Know Your Business (KYB) Process

Know Your Business (KYB) is the primary defensive mechanism used by fintech gateways. Unlike Know Your Customer (KYC), which focuses on individuals, KYB requires a deeper exploration of corporate hierarchies.

The Verification Objectives:

• Legal Existence: Proving the business is a real, registered entity.
• Control Disclosure: Identifying the Ultimate Beneficial Owners (UBOs) to prevent the use of shell companies for illicit activities.
• Risk Scoring: Evaluating the industry, geography, and transaction profile of the merchant.

The INXY Payments Verification Workflow: A Step-by-Step Guide

The verification process is designed to be rigorous yet streamlined, ensuring all participants meet EU compliance standards. This is a unified process applicable to all merchants, regardless of their industry or integration method.

Step 1: Initial Company Data Intake

The process commences with the "Company data form." The merchant must enter fundamental identifying information, including the legal Company Name, official Registration Number, and Country of Registration.

Note: Providing a direct company email is recommended to ensure a clear line of communication with compliance officers.

‍

Step 2: Comprehensive Documentation Upload

Merchants must validate their legal status by uploading a robust evidentiary file. Mandatory documents typically include:

• Certificate of Incorporation / Business Registration: Proof that the entity exists in a government registry.
• Articles of Association (AOA): Defines the entity's operations and leadership structure.
• Operating License: Required only if the merchant operates in a specifically regulated sector (e.g., gambling, forex).

‍

Step 3: Ultimate Beneficial Owner (UBO) Identification

Identifying the natural persons who ultimately control the entity is the cornerstone of EU AML regulations.

• The 25% Rule: Merchants must identify any natural person holding more than 25% of ownership shares or voting rights.
• Verification: For each UBO, the system requires their full name, date of birth, and contact details. Identity verification can be performed live or via a secure link sent to the stakeholder.

Step 4: Shareholder and Representative Verification

• Corporate Shareholders: If a shareholder is another company, the merchant must provide that entity's Articles of Association and trace the ownership chain back to a natural person.
• Legal Representative: Data must be provided for the person acting on behalf of the company, ensuring they have the legal authority (e.g., Director status or Power of Attorney) to open financial accounts.

Step 5: Final Validation and Submission

The penultimate step is a thorough review of all provided data. Once confirmed, the application enters the compliance review queue. Thanks to automated systems, merchants can track their status in real-time via their dashboard.

‍

‍

Document Requirements and Authentication Standards

The integrity of the verification process relies entirely on the quality of the documentation. The European fintech environment maintains a high bar for validity.

Mandatory Conditions for Approval:

• Language: All documents must be in English. If the original is in another language, a notarized translation is required.
• Authentication: Documents must be "official," bearing the necessary stamps, signatures, or qualified electronic seals as per local laws.
• Recency: Extracts from commercial registries generally should not be older than 3 months to ensure the data is current.

Common Reasons for Rejection:

• Typos: Mismatches between the input form and the uploaded PDF.
• Missing Pages: Uploading incomplete Articles of Association.
• Low Quality: Blurry scans or photos where text is illegible.

Security and Data Protection (GDPR & DORA)

The sensitive nature of KYB data requires the highest levels of protection.

• GDPR Compliance: Data is used solely for client identification and activity justification, adhering to the principle of "Purpose Limitation."
• DORA (Digital Operational Resilience Act): Mandates that payment gateways demonstrate resilience against cyber threats. Data is encrypted at rest and in transit, with role-based access ensuring only authorized compliance personnel can view identity files.

‍

Conclusion: Compliance as a Competitive Advantage

Completing the merchant verification process is more than a regulatory hurdle; it is a strategic move that positions a business as a credible player in the global economy. By adhering to this standardized verification workflow, merchants—whether they are hosting providers, e-commerce stores, or digital service agencies—secure a stable, bank-grade foundation for their financial operations.

In the mature crypto economy of 2026, a verified account is the key to unlocking global markets, ensuring seamless settlements, and protecting business capital from regulatory friction.

‍

USDT is a single asset, but it lives on more than a dozen blockchains — and the network you choose can change the cost of a transfer by 100x or more. For a one-off payment that's a rounding error. For a business sending thousands of payouts a month, picking the wrong chain quietly burns thousands of dollars.

‍

This is a practical breakdown of the cheapest network to send USDT in 2026, what drives the fee on each chain, and how to match the network to the payout.

Why USDT fees vary so much

The fee to move USDT has nothing to do with Tether itself. It's the network's gas fee — paid in the chain's native token — that varies:

‍

• On Ethereum (ERC-20) you pay ETH gas, which is priced by network congestion and can spike sharply.
• On Tron (TRC-20) you pay in TRX energy/bandwidth, which is low and stable.
• On Solana, TON, and BNB Chain, base fees are engineered to be very small.

‍

So "how much does it cost to send USDT" is really "which network did you send it on."

USDT fee comparison (2026)

Approximate, indicative costs — real fees move with congestion and the native token price. Use this for relative comparison, not exact quotes.

‍

‍

The short version: for pure on-chain cost, Solana and TRC-20 lead, with TON unbeatable for exchange withdrawals. ERC-20 is the most expensive and should be reserved for recipients who specifically need it.

Match the network to the payout amount

Cheapest isn't always "correct." The right network depends on the size of the transfer and where the recipient wants the funds.

‍

• Micro-payouts (under ~$50): TRC-20, Solana, or TON. Fees would otherwise eat a meaningful slice of the payment.
• Standard payouts ($50–$5,000): Solana, Polygon, or TRC-20 keep costs to pennies while settling fast.
• Large transfers (over ~$5,000): Cost matters less relative to the amount. ERC-20 is acceptable if the counterparty requires it — the $10–20 fee is small against the principal, and Ethereum's liquidity and integrations are unmatched.

Beyond the headline fee

Fee-per-transfer is the obvious number. Three others matter just as much at scale:

‍

1. Recipient acceptance. The cheapest network is useless if the recipient's wallet or exchange doesn't support it. Always confirm the network before sending — cross-network mistakes are irreversible.

‍

2. Native-token overhead. Every network needs its gas token in your wallet. Running payouts across five chains means monitoring and topping up five different balances — an operational cost that doesn't show up in the per-transfer fee.

‍

3. Failed and stuck transfers. Underpriced gas on congested networks means stuck transactions and support tickets. Reliability has a cost, too.

How platforms cut costs further

When you run payouts through a fiat-native platform instead of manually, network fees stop being your problem in two ways:

‍

• Automatic routing. The platform sends each payout on a supported low-fee network without you managing gas on every chain.
• No native-token juggling. You fund a balance in EUR or USD; the provider handles conversion and gas. Your reporting stays in fiat.

‍

That removes the hidden operational cost of multi-chain payouts, not just the visible per-transfer fee.

Frequently asked questions

What is the cheapest network to send USDT? For on-chain self-custody transfers, Solana and Tron (TRC-20) are cheapest, and TON offers the lowest withdrawal fees on major exchanges. Ethereum (ERC-20) is the most expensive.

‍

Is TRC-20 always the cheapest for USDT? Not always. TRC-20 is very cheap and has the deepest USDT liquidity, but Solana and TON can be cheaper still per transfer. TRC-20 remains the most widely accepted low-fee option.

‍

Why is sending USDT on Ethereum so expensive? ERC-20 transfers pay ETH gas, priced by network demand. During congestion, a single USDT transfer can exceed $30 in gas.

‍

Does the network affect how much USDT the recipient receives? The network sets the fee you pay to send. Choosing a low-fee chain means more of your budget reaches recipients, especially across many small payouts.

‍

Can I send USDT across networks? An address is tied to one network. To move USDT between chains you need a bridge or an exchange — you can't send TRC-20 USDT directly to an ERC-20 address.

Send on the right network, automatically

If you're running regular USDT payouts, you shouldn't be managing gas tokens across five blockchains. INXY's mass USDT payouts route each transfer over low-fee networks and report everything back in EUR or USD — so you get the cheapest path without the multi-chain overhead. New to bulk sending? Start with our step-by-step USDT payout guide.

‍

If your business sends crypto payouts — to contractors, suppliers, affiliates, or partners — the crypto Travel Rule now sits between you and every transfer. It is the single piece of kyc aml crypto payments regulation most likely to delay, freeze, or return a B2B payout in 2026, and most senders only learn about it after a payment is held. This guide explains what the Travel Rule is, how the 2026 rules differ by region, what data must accompany each payout, and how a regulated crypto gateway runs the checks so you don't have to build a compliance stack yourself.

What the crypto Travel Rule is (and why it now applies to your payouts)

The Travel Rule is an anti-money-laundering standard that requires identifying information about the sender (originator) and recipient (beneficiary) to "travel" alongside a transfer of value. It originated in traditional banking and now applies to crypto.

FATF Recommendation 16, extended to crypto

The rule comes from the Financial Action Task Force (FATF), whose Recommendation 16 was extended in 2019 to cover virtual assets. The principle is simple: when a regulated provider moves crypto on a customer's behalf, it must collect, transmit, and retain originator and beneficiary details so that law enforcement can trace funds. FATF recommendations are influential but not law in themselves — each jurisdiction decides how to implement them, which is why the picture is fragmented (more on that below).

Who counts as a VASP — and when you are the originator

The obligation falls on Virtual Asset Service Providers (VASPs): exchanges, custodial wallet providers, and crypto payment gateways. When your business initiates a payout through such a provider, the provider is the "originating institution" and carries the Travel Rule duty — but it can only meet that duty with your data. In practice this means the gateway must know who you are paying and why, and you must be able to supply recipient details on demand. The compliance burden is shared: the provider operates the machinery, but incomplete sender data is the most common reason a payout stalls.

The 2026 regulatory picture: crypto compliance and regulations by region

By 2026, over 50 jurisdictions have enacted Travel Rule legislation — roughly 73% of FATF-assessed jurisdictions, up from a far smaller base two years earlier. Enforcement maturity, thresholds, and required data still vary widely, so a payout that is routine in one corridor can be blocked in another.

EU — Transfer of Funds Regulation (TFR), no de-minimis threshold

The EU's recast Transfer of Funds Regulation (TFR) took effect on 30 December 2024. It is the strictest major regime: full originator and beneficiary data must accompany every crypto-asset transfer handled by a regulated provider, with no minimum threshold. A €5 payout and a €500,000 payout carry the same data obligation. The TFR operates alongside MiCA, the EU's broader crypto-asset framework, which governs licensing of providers.

US — Bank Secrecy Act Travel Rule, USD 3,000 threshold

In the United States the Travel Rule lives under the Bank Secrecy Act (BSA), administered by FinCEN, with a threshold of USD 3,000 — notably higher than FATF's recommendation. A 2026 development matters for stablecoin senders: following the GENIUS Act (signed July 2025), the U.S. Treasury proposed a rule on 8 April 2026 treating permitted stablecoin issuers as BSA financial institutions, subject to AML programs, recordkeeping, and the Travel Rule, with compliance expected around April 2027. The direction of travel is clear — stablecoin rails are being pulled fully into the same compliance perimeter as the banking system.

FATF global threshold and the "sunrise problem"

FATF recommends a standard threshold of USD/EUR 1,000, below which a reduced data set may apply. Because jurisdictions adopt the rule at different speeds, the industry faces the "sunrise problem": a compliant provider in a regulated market may need to send Travel Rule data to a counterparty in a market that has not yet implemented the rule and cannot receive it. For B2B senders this means a payout's success can depend on the recipient platform's jurisdiction, not just your own.

‍

What data must "travel" with a B2B crypto payout

The required data set is consistent across regimes, even where thresholds differ.

Required originator (sender) fields

• Name of the originator (your business or the paying entity).
• Wallet address used for the transfer (or a transaction reference).
• Physical/registered address, and in some regimes an official identifier or account number.

Required beneficiary (recipient) fields

• Name of the recipient.
• Wallet address receiving the funds.

‍

In addition, the transaction amount, execution date, and a unique transaction identifier are recorded with every transfer. For your operations, the practical takeaway is that recipient name + wallet must be accurate and verifiable before you send — a mismatch is a hold.

Self-hosted (unhosted) wallet payouts — the extra step

Paying out to a self-hosted (non-custodial) wallet — common when paying contractors or partners who hold their own keys — changes the mechanics. There is no counterparty VASP to receive the Travel Rule message, so the data isn't transmitted onward; instead, your provider must still collect originator and beneficiary information from you, and above the relevant threshold may require verification of wallet ownership based on a risk assessment. Expect to attest that the recipient controls the destination address for larger payouts.

How a regulated crypto gateway runs the Travel Rule on outbound payouts

This is where a regulated crypto gateway earns its keep. Rather than connecting to Travel Rule messaging protocols, screening providers, and sanctions lists yourself, the gateway runs the controls inside the payout flow. Using INXY's outbound model as a concrete example, an outgoing payout passes through several gates before any transfer is created.

Pre-send checks — address risk and blacklist screening

A payout starts as a withdrawal request, not an immediate send. A pre-send validation stage runs first and can stop the operation with an error so that no transaction is ever formed. As part of this, the recipient address is looked up against historical risk data: a previously unseen address is treated cautiously, while a known address carries its last risk result. This means a problematic payout is caught at draft stage, not after funds have left.

KYT/AML screening of the recipient

Next is the outbound KYT (Know Your Transaction) sequence. The recipient address is checked against a blacklist; a match fails the request outright with no transaction created. If it clears, a risk provider screens the address and returns an outcome:

‍

• Low or Medium → the payout draft passes and proceeds.
• High → the request fails, no transaction is created, and an error is returned.

‍

This is the kyc aml crypto payments layer working in real time on the money leaving your account.

The Travel Rule message exchange

Only after screening passes does the Travel Rule step run, packaging and exchanging the required originator/beneficiary information with the counterparty provider where one exists. The payout then proceeds to settlement. The sequence matters: screen first, transmit data, then send.

Approved contacts and recipient allow-lists

Gateways typically maintain a contact list of approved recipients. A recipient flagged as declined blocks the payout regardless of other checks — a useful control for finance teams that want a vetted, reusable set of payees for recurring or mass payouts.

‍

KYB is the gate to the platform; KYT is the gate to each transaction; the Travel Rule is the data that rides along with it. A gateway that handles all three is what "secure crypto payments" actually means in operational terms.

Compliance risks of getting payouts wrong

For a B2B sender, Travel Rule failures are not abstract — they hit cash flow and counterparties directly:

‍

• Held or returned transfers. Missing or mismatched recipient data is the most common cause of a stalled payout. Funds can sit in review or be returned, delaying contractor and supplier payments.
• Counterparty refusal. If the receiving platform can't accept Travel Rule data (the sunrise problem) or flags your transfer, it may bounce the payment.
• Regulatory exposure. Operating outbound flows without proper screening and recordkeeping exposes the business to AML penalties — increasingly so as stablecoin issuers are folded into BSA-style obligations.
• Operational drag. Building and maintaining screening, sanctions, and Travel Rule messaging in-house is expensive and never "done," because rules and thresholds keep shifting.

How to automate crypto payouts without owning the compliance stack

The practical answer for most B2B senders is to run payouts through a regulated crypto gateway that treats the Travel Rule, KYT, and sanctions screening as part of the payout itself — not as something you bolt on.

‍

With INXY, every outbound payout passes through pre-send validation, blacklist and KYT risk screening, and the Travel Rule step before settlement, and recurring payees can be managed through an approved contact list. Because the same flow is exposed via API and webhooks, you can run mass payouts — paying hundreds of contractors or partners at once — with compliance checks applied per recipient automatically, and receive status events back into your own systems. That is what "how to automate crypto payouts" looks like when compliance is built in rather than improvised.

‍

If compliance posture is your priority, start with INXY's security & compliance capabilities; if payout mechanics are the focus, see crypto payouts and the cross-border and payroll options that build on the same rails.

FAQ

Does the Travel Rule apply to stablecoin payouts? Yes. Stablecoin transfers handled by a regulated provider are subject to the Travel Rule like any other virtual asset. In the EU, full data is required regardless of amount; in the US, stablecoin issuers are being brought explicitly into BSA Travel Rule obligations under a rule proposed in April 2026.

‍

What is the Travel Rule threshold in 2026? It depends on the jurisdiction. FATF recommends USD/EUR 1,000; the US applies USD 3,000 under the BSA; the EU applies no threshold — every transfer carries full data.

‍

Do I need to collect data for self-hosted (unhosted) wallet payouts? Yes. Even though there's no counterparty provider to receive the message, your gateway must still collect originator and beneficiary information, and above the relevant threshold may require proof that the recipient controls the destination wallet.

‍

Is the Travel Rule the same as KYC? No. KYC/KYB verifies identity at onboarding. The Travel Rule governs the transmission of identity data alongside each transfer. They work together but are distinct obligations.

‍

Who is responsible — the sender or the recipient platform? Both sides carry obligations. The originating provider must collect and transmit sender/recipient data; the beneficiary provider must receive and retain it. As the business initiating the payout, you're responsible for supplying accurate recipient information to your provider.

‍