MiFID II -- the Markets in Financial Instruments Directive -- is the foundational regulatory framework governing investment firms across the European Economic Area. While most compliance discussions focus on its provisions around best execution, product governance, and transparency, MiFID II has profound and often underappreciated implications for how forex brokers process payments. The directive's requirements around client money handling, source of funds verification, and transaction monitoring directly shape the operational architecture of a broker's payment infrastructure.

In my experience leading compliance programs for regulated forex brokers and now at Proxy.forex, the most common compliance failures are not deliberate violations. They are gaps that emerge because the payment processing system was designed without regulatory requirements in mind. A broker may have robust KYC procedures but no systematic way to verify that deposit payment methods match the verified client identity. Or they may have transaction monitoring in place but lack the structured data needed to generate the suspicious transaction reports that regulators require. These are infrastructure problems, not policy problems.

This guide provides a practical, implementation-focused walkthrough of the MiFID II provisions that directly affect payment processing. It is written for compliance officers, payment operations teams, and CTOs at CySEC, FCA, and ASIC-regulated forex brokers who need to ensure their payment infrastructure meets regulatory expectations.

MiFID II and Payment Processing: Why It Matters

MiFID II does not regulate payment processing directly -- that falls under PSD2 and its successor PSD3. However, MiFID II imposes obligations on investment firms (including forex brokers) that have direct operational implications for how payments are handled. Article 16(8) of MiFID II requires investment firms to make “adequate arrangements” to safeguard client financial instruments and funds. The implementing regulation (Commission Delegated Regulation EU 2017/565) further specifies requirements around the segregation, identification, and reconciliation of client money.

For payment processors serving MiFID II-regulated brokers, this creates a set of downstream requirements. Every deposit must be traceable from the trader's funding source through the payment processor to the broker's segregated client money account. The payment processor must support the data structures and audit trails that allow the broker to demonstrate compliance with these obligations during regulatory examinations. A payment processor that treats forex deposits as generic transactions without regulatory metadata is a compliance liability for the broker.

The financial penalties for non-compliance are significant. CySEC has imposed fines exceeding EUR 1 million for client money handling failures. The FCA has levied penalties in the tens of millions of pounds for AML/CFT deficiencies in the investment services sector. ASIC has revoked licenses entirely where client money segregation was found to be inadequate. The regulatory risk is not theoretical -- it is an ongoing enforcement reality.

Client Money Segregation Rules

The cornerstone of MiFID II client protection is the requirement that client funds be segregated from the firm's own funds. Article 2 of the Commission Delegated Regulation specifies that client money must be held in accounts clearly identified as client accounts, opened with approved institutions (typically banks or qualifying money market funds). The practical implication for payment processing is that every deposit must be routed to a designated client money account, not to the broker's operational or corporate account.

Payment processors must support settlement into broker-designated segregated accounts. This sounds straightforward, but in practice it creates complexity. If a broker uses multiple acquirers across different jurisdictions, each acquirer may settle into a different bank account. The broker must ensure that all settlement accounts are properly designated as client money accounts, that the payment processor's settlement instructions correctly reference these accounts, and that the reconciliation between transactions processed and funds settled can be performed on a daily basis.

Additionally, client money regulations in most jurisdictions require a daily reconciliation between the amount owed to clients (based on trading account balances) and the amount held in segregated accounts. The payment processor's reporting capabilities are critical here -- the broker needs transaction-level settlement reports that can be reconciled against their internal ledger to identify any discrepancies. A payment processor that provides only aggregate settlement amounts without transaction-level detail makes this reconciliation significantly more difficult.

Source of Funds Requirements

Under the Fourth and Fifth Anti-Money Laundering Directives (4AMLD/5AMLD), which operate alongside MiFID II, investment firms must verify the source of funds used to finance trading activity. For payment processing, this translates into a requirement that the payment method used for a deposit can be linked to the verified identity of the account holder. In plain terms: the name on the card or bank account used for a deposit must match the name of the verified trading account holder.

Third-party deposits -- where someone other than the account holder funds a trading account -- are a significant compliance risk area. Most regulators either prohibit third-party deposits entirely or require enhanced due diligence when they are accepted. The payment processor must provide the broker with sufficient information to make this determination: the cardholder name (for card payments), the account holder name (for bank transfers), and the wallet address provenance (for cryptocurrency deposits).

The challenge is particularly acute for card payments, where the cardholder name available to the payment processor may not exactly match the name in the broker's KYC records due to transliteration differences, middle names, or name ordering conventions. Payment processors should provide fuzzy name-matching capabilities or at minimum expose the raw cardholder data so that the broker's compliance team can perform the matching. At Proxy.forex, we include cardholder verification as part of our deposit enrichment pipeline, flagging transactions where the cardholder name shows a low confidence match to the verified trader identity.

Transaction Monitoring Obligations

Both MiFID II and AML directives require investment firms to maintain ongoing monitoring of client transactions to detect patterns that may indicate market abuse, fraud, or money laundering. For the payment dimension specifically, this means monitoring deposit and withdrawal patterns for anomalies: rapid cycling of funds (depositing and immediately withdrawing without trading), deposits significantly exceeding the client's stated income or wealth profile, multiple deposits from different payment methods in a short period, and geographic inconsistencies between the client's verified address and the payment origin.

Effective transaction monitoring requires structured, high-quality data from the payment processor. Each transaction must carry metadata including the payment method type, the issuing country of the card or originating bank of the transfer, the transaction amount in both the original and settled currencies, timestamps with timezone information, and unique identifiers that allow the transaction to be traced through the entire processing chain. Without this data, the broker's monitoring systems cannot apply the rules and thresholds that detect suspicious patterns.

The frequency of monitoring is also a regulatory consideration. While batch monitoring (daily or weekly reviews) may have been acceptable in previous years, regulators increasingly expect near-real-time monitoring capabilities. CySEC's Circular C445 specifically references the expectation that firms have “automated systems capable of identifying unusual or suspicious transactions in a timely manner.” Payment processors that provide real-time webhook notifications for transactions, declines, chargebacks, and refunds enable brokers to implement the continuous monitoring that regulators expect.

Suspicious Transaction Reporting

When transaction monitoring identifies a potentially suspicious pattern, the broker is obligated to file a Suspicious Transaction Report (STR) with the relevant Financial Intelligence Unit (FIU) -- MOKAS in Cyprus, the NCA in the UK, or AUSTRAC in Australia. The STR must include detailed information about the transactions in question, the client involved, and the basis for the suspicion. This is where the quality of payment data becomes directly relevant to regulatory compliance.

A well-structured STR for a payment-related suspicion requires: the complete transaction history for the client, including payment method details for each deposit and withdrawal; the IP addresses and device fingerprints associated with each transaction; any declined transactions that may form part of the suspicious pattern; the timeline of KYC verification relative to transaction activity; and the specific monitoring rules or thresholds that were triggered. Payment processors must be able to provide this data in a structured, exportable format on demand.

It is worth noting that under Article 16 of MiFIR (Markets in Financial Instruments Regulation), investment firms also have an obligation to report suspicious orders and transactions that may constitute market abuse to the relevant competent authority. While this obligation primarily relates to trading activity, payment patterns can be relevant evidence -- for example, a pattern of deposits immediately preceding significant market events could indicate insider trading. The intersection of payment monitoring and market surveillance is an area where regulatory expectations are expanding.

CySEC vs FCA vs ASIC: Key Regulatory Differences

While MiFID II provides the overarching framework, individual national regulators implement and enforce its provisions with notable differences. CySEC (Cyprus Securities and Exchange Commission) has been particularly focused on payment processing compliance in recent years, issuing specific circulars addressing third-party deposits, payment method verification, and the use of payment agents. CySEC expects brokers to verify that the payment method belongs to the account holder before processing the first withdrawal, and prohibits the use of credit cards for funding trading accounts in certain circumstances.

The FCA (Financial Conduct Authority) in the UK, while no longer directly subject to MiFID II post-Brexit, has incorporated its principles into the UK regulatory framework through the FCA Handbook. The FCA places particular emphasis on the adequacy of client money protection, with detailed rules in CASS 7 (Client Assets Sourcebook) that go beyond MiFID II's minimum requirements. FCA-regulated brokers must maintain client money with approved banks under specific title protections, perform daily and monthly reconciliations, and notify the FCA promptly of any client money shortfalls.

ASIC (Australian Securities and Investments Commission) operates under a separate legislative framework (the Corporations Act 2001) but shares similar objectives around client money protection. Following the significant reforms implemented in 2022, ASIC-regulated brokers face strict requirements around the holding of retail client money in Australian ADI (Authorized Deposit-taking Institution) accounts. For brokers operating across multiple jurisdictions, the payment processor must be able to route settlements to jurisdiction-appropriate segregated accounts and provide the regulatory reporting needed for each authority.

KYC and CDD Requirements for Payment Processors

While the primary KYC (Know Your Customer) and CDD (Customer Due Diligence) obligations fall on the broker as the regulated entity, payment processors play a supporting role that is becoming increasingly formalized. The broker must verify the client's identity before allowing them to trade. However, the payment processor must verify that the payment method used is consistent with that verified identity -- a concept sometimes called “payment method verification” or “funding source verification.”

In practice, this means the payment processor should provide the broker with: the cardholder name and issuing bank for card deposits; the account holder name and BIC/SWIFT code for bank transfers; the wallet address and blockchain analytics results for cryptocurrency deposits; and any additional verification data available from the payment network (such as AVS results for card transactions). This data allows the broker to confirm that the funding source belongs to the verified account holder and to flag any discrepancies for compliance review.

Enhanced Due Diligence (EDD) is required for clients who present higher money laundering risk -- Politically Exposed Persons (PEPs), clients from high-risk jurisdictions listed by FATF, or clients whose transaction patterns trigger monitoring alerts. For the payment dimension, EDD may include requirements such as obtaining documentary proof of the source of funds (bank statements, pay slips), limiting the payment methods available to the client, or applying lower transaction thresholds before requiring additional verification. The payment processor's API must support these configurable controls at the individual client level.

PSD2 Strong Customer Authentication and MiFID II Interaction

The Payment Services Directive 2 (PSD2) introduced Strong Customer Authentication (SCA) requirements for electronic payments in the EEA. SCA requires two-factor authentication for online card payments, which is typically implemented through 3D Secure 2 (3DS2). For forex deposits, SCA creates both compliance obligations and operational challenges that interact with MiFID II requirements.

The compliance interaction is straightforward: card deposits by EEA-based traders must include SCA unless an exemption applies. The available exemptions -- low-value transactions (under EUR 30), trusted beneficiary listings, and transaction risk analysis (TRA) -- each have specific conditions and thresholds. The TRA exemption is particularly relevant for forex because it allows transactions below certain thresholds to bypass SCA if the acquirer's fraud rate is below specified benchmarks. Payment processors must track their fraud rates at the acquirer level and apply the correct exemption logic for each transaction.

The operational challenge is that SCA adds friction to the deposit flow. The trader must complete an authentication step with their issuing bank, which typically involves a redirect to the bank's authentication page or a push notification to the bank's mobile app. This additional step reduces deposit completion rates by 5-15% depending on the issuer's authentication user experience. The payment processor must implement SCA selectively -- applying it where required by regulation but avoiding it where exemptions are available -- to minimize unnecessary friction while maintaining compliance. This selective application logic must be updated as SCA regulations evolve, particularly with the upcoming PSD3 revisions.

Record-Keeping and Audit Trails

MiFID II Article 16(6) requires investment firms to maintain records of all services, activities, and transactions “sufficient to enable the competent authority to fulfil its supervisory tasks.” For payment transactions, this means retaining detailed records for a minimum of five years (seven years in some jurisdictions) from the date of the transaction. The records must include the complete transaction details, the payment method used, the processing outcome, any decline or error codes, the routing path through the payment infrastructure, and any compliance actions taken (such as enhanced verification or transaction blocking).

The audit trail requirements are particularly demanding during regulatory examinations. Regulators may request the complete payment history for a specific client, all transactions within a date range matching specific criteria, or a detailed walkthrough of how a particular transaction was processed from initiation through settlement. The payment processor must provide APIs or export capabilities that allow the broker to retrieve this data on demand, in a structured format that can be presented to regulators.

At Proxy.forex, we maintain immutable transaction logs that capture every event in the transaction lifecycle: the initial deposit request, the routing decision, the acquirer submission, the authorization response, any retry attempts, the settlement confirmation, and any subsequent events (chargebacks, refunds, reversals). These logs are stored in a time-series database with a seven-year retention policy and are accessible through both a dashboard interface and a programmatic API. This infrastructure ensures that our broker clients can produce the audit trails that regulators require without manual data assembly.

Practical Compliance Checklist for Brokers

Based on our experience working with dozens of regulated forex brokers, here is a practical checklist for ensuring your payment processing infrastructure meets MiFID II and related regulatory requirements. This is not a substitute for legal advice, but it provides a solid operational framework.

Common Compliance Failures and Regulatory Fines

Understanding where other brokers have failed is instructive for strengthening your own compliance posture. The most common payment-related compliance failures that lead to regulatory action fall into several categories. Client money commingling -- where client deposits are temporarily or permanently mixed with the broker's operational funds -- remains the most serious violation. This can happen subtly: an acquirer settles into a corporate account instead of a segregated account, or a broker uses client money to cover operational expenses during a cash flow shortage.

Inadequate source of funds verification is another frequent finding. Regulators have penalized brokers who accepted large deposits without verifying the source, particularly for clients flagged as higher risk. In one notable CySEC enforcement action, a broker was fined EUR 750,000 for systematically accepting deposits without verifying that the depositing payment method matched the verified client identity, enabling potential money laundering through the use of third-party cards.

Deficient transaction monitoring is a growing area of enforcement. The FCA fined a major financial institution GBP 37.8 million for AML failures that included inadequate transaction monitoring systems. While this was not a forex-specific case, the principles apply directly: regulators expect automated, risk-based monitoring that operates continuously and generates alerts for investigation. Manual, periodic reviews of transaction data are no longer considered adequate. The payment processor's role in providing the real-time data feeds and structured metadata that power these monitoring systems is increasingly recognized as a critical component of the compliance infrastructure.

Finally, poor record-keeping consistently appears in enforcement actions. Regulators report finding gaps in transaction audit trails, missing decline and chargeback records, and an inability to reconstruct the complete lifecycle of historical transactions. These failures typically reflect technical debt in the payment infrastructure rather than intentional non-compliance, but regulators do not distinguish between the two in their enforcement decisions. Investing in comprehensive, immutable transaction logging is not optional -- it is a regulatory requirement with real financial consequences for non-compliance.