Quick answer: A forex broker should choose a payment service provider by confirming who provides each service, under which permission, for which broker entity, markets, currencies and funds. Price should come later. A provider may be suitable for company payments but not client deposits; an electronic money institution may safeguard certain payment funds but not satisfy the broker’s client-money rules; and a technical gateway may connect an interface without being the merchant acquirer. The safest process is to verify the legal entity and regulatory scope, map the end-to-end money flow, test product and country acceptance, allocate AML and data responsibilities, examine safeguarding and settlement terms, prove reconciliation, and plan continuity and exit before comparing headline fees.
Information last verified on 30 August 2026. This article provides a general due-diligence and implementation framework. Provider permissions, client-money rules, payment protections and contractual rights vary by jurisdiction, service, account and legal entity. It is not legal advice, a provider recommendation or a prediction of onboarding, settlement speed, pricing or service continuity.
What does “PSP” mean for a forex broker?
Payment service provider is a functional umbrella term, not one universal licence class. A bank, payment institution, electronic money institution, merchant acquirer, payment facilitator, money transmitter, gateway or technical processor may perform different parts of the payment chain. A single commercial brand can also use several licensed entities, agents, sponsor banks and local partners.
The broker should first define the function it needs: company operating payments, client collection, merchant acquiring, payouts, currency conversion, safeguarded payment balances or settlement to another account. Calling all of these functions a “payment channel” conceals who holds money and who is legally responsible.
| Provider role | Possible function | What to verify | What the label does not prove |
|---|---|---|---|
| Bank or credit institution | Deposit accounts, transfers and other banking or payment services within its permission | Exact bank entity, account holder, currencies, country scope, account purpose and applicable deposit protection | That a PSP’s partner bank has opened a direct account for the broker |
| Payment institution | Payment execution, money remittance or other authorised payment services | Permission category, specific services, home and host countries, branches and agents | Authority to accept deposits or perform every service offered by a bank |
| Electronic money institution | Electronic-money issuance and permitted payment services | Which balances are e-money, redemption rights, safeguarding method and unrelated services | That every balance is a bank deposit or covered by government deposit insurance |
| Merchant acquirer or payment facilitator | Contracts for payment acceptance and processing so funds can be settled to the merchant | Acquirer of record, merchant or sub-merchant status, payment methods, countries, reserve and chargeback duties | That a gateway or branded checkout is itself the regulated acquirer |
| Gateway or technical processor | Transmits or processes payment data and connects systems | Whether it touches funds, its data role, the actual acquirer and service dependencies | Permission to acquire transactions or hold money merely because it supplies an API |
| Money transmitter, MSB or sponsored arrangement | Money movement or embedded payment functions under the relevant local structure | Exact activity, local licences or registrations, sponsor, underlying accounts and responsibility allocation | A bank licence or one permission that authorises global service |
Start with the payment architecture, not the fee schedule
A provider cannot be assessed without a transaction-level flow map. The map should identify the payer, client, broker counterparty, merchant, account holder, PSP, acquirer, safeguarding institution, settlement bank and final payee. It should also state when funds are client money, payment-service-user funds, merchant receivables or the broker’s own revenue.
The same group should not use a licence held by one entity, a client contract issued by another and a merchant account owned by a third without a documented legal and commercial basis. Our forex broker company-structure guide explains how ownership, contracts and money flows should align. The separate corporate bank account guide for forex brokers covers operating, capital, client-money and settlement account architecture.
| Flow event | Questions to resolve before selection | Data and evidence needed after launch |
|---|---|---|
| Client initiates a deposit | Who is the payee, which broker entity is the client counterparty, and may a third party pay? | Payer identity, client ID, country, currency, amount, purpose and unique transaction reference |
| Gateway sends the request | Is the gateway only technical, and which acquirer or PSP actually accepts the payment? | Request, authentication result, status changes, failure reason and provider references |
| Provider receives or controls funds | Which legal entity holds the money, in what type of account, and for whose benefit? | Transaction ledger, account designation, safeguarding records where applicable and balance ownership |
| Transactions are bundled or netted | Can the broker and upstream institutions still identify underlying payers, payees and purposes? | Gross transaction file, fees, refunds, reserves and bridge from gross activity to net settlement |
| Funds settle to the broker | When does settlement become available, in which currency, and to which permitted account? | Settlement report, bank credit, conversion record, fees and general-ledger posting |
| Client requests a withdrawal or refund | Which route, ownership checks and approvals apply, and who bears a chargeback or failed payout? | Instruction, screening, approval, destination ownership, status and accounting entry |
Bulk and nested payment structures require particular care because one institution may see only a net settlement from another PSP rather than each underlying client. The contract and data design should state who performs due diligence, sanctions screening, transaction monitoring and exception investigation at every layer.
Verify the provider’s legal entity, permission and register status
A provider’s brand name is not enough. Ask for the contracting entity’s full legal name, company and regulatory numbers, registered address, licence or registration category, and the name of any agent, branch, distributor, acquirer or sponsor used for the proposed service. Cross-check those details on the relevant official register and, where a regional register aggregates data, confirm the national competent authority record.
Finding a name on a register is only the first test. Confirm that the permission covers the actual activity, such as payment execution, money remittance, electronic-money issuance or merchant acquiring. Determine whether the entity is fully authorised, subject to a limited or exempt category, acting as an agent, or only supplying technology. Check current status, restrictions and the countries in which the service is legally and operationally available.
Regulation does not guarantee that the provider accepts forex or CFD brokers, every licence jurisdiction, every client country or every payment method. Obtain written confirmation for the precise broker entity, products, client model and flows. The upstream question of how a broker’s regulatory framework affects banking and payment explainability is covered in our forex licence, banking and PSP onboarding guide.
Test products, markets, currencies and payment methods in writing
“Financial services accepted” and “global coverage” are not sufficiently precise. The provider may allow company payments but prohibit client collection, allow bank transfers but not card acquiring, or support a country for merchant settlement while declining payers resident there. Restrictions can arise from law, licensing, sponsor banks, card schemes, local partners and the provider’s own risk policy.
Create a country-and-product schedule that distinguishes the broker’s licensed jurisdiction, client residence, payer country, payee country, settlement location and marketing activity. Cross-border availability is not proof that the broker may solicit clients in each market. Use our regional client-market and forex licence framework for that separate legal-access analysis.
Ask the provider to confirm:
- the permitted forex, CFD or other investment products and retail or professional client types;
- allowed client, payer, beneficiary and settlement countries;
- supported currencies, collection methods, payout methods and conversion points;
- treatment of third-party payments, affiliates, introducing brokers, white labels and bulk payouts;
- transaction and balance limits, seasonal peaks and the process for approving growth; and
- prohibited marketing practices, funding sources, payment descriptions and use cases.
The written schedule should form part of the contract or controlled onboarding record. A sales email or dashboard option can help clarify scope but should not override legal terms, provider permissions or restrictions imposed by an upstream partner.
Separate PSP safeguarding from the broker’s client-money duties
Two legal questions must be answered independently. First, does the PSP have to safeguard particular payment or electronic-money funds, and how does it do so? Second, may the forex broker place or route its investment-business client money through that provider and account under the broker’s own rules?
Safeguarding may involve segregation, a designated account, eligible assets, insurance or a comparable guarantee, depending on the regime and provider category. It applies to defined funds, not automatically to every fee, reserve, settlement balance or company payment held within the same interface. Ask which entity bears the duty, when protection begins and ends, which institution holds the funds, how individual entitlements are recorded, how reconciliations and shortfalls are handled, and what happens on provider insolvency.
Safeguarding is not the same as a bank deposit or government deposit insurance. A non-bank account number or named payment account does not by itself prove that the broker owns a direct bank deposit. Even a properly safeguarded balance can involve return delays, insolvency administration costs or factual disputes. Any statement about deposit protection should identify the actual bank, account holder, currency, records and eligibility conditions.
The broker’s client-money rules may limit eligible institutions, require specific account titles or acknowledgements, impose segregation and reconciliation duties, or prohibit the broker from holding client assets. A provider’s marketing words “segregated” or “safeguarded” cannot replace that analysis. A collection route should not go live until legal, compliance, treasury and accounting teams agree how each fund type is classified and recorded.
Build an AML, sanctions and fraud responsibility matrix
A PSP’s screening does not automatically replace the broker’s KYC, AML, sanctions, transaction-monitoring or client-money obligations. Operational tasks may be allocated or outsourced only within the applicable legal framework, while statutory responsibility may remain with one or both parties. The contract and operating procedures should show who performs each control, what data is exchanged and who handles an alert.
| Control | Broker questions | Provider questions | Evidence and escalation |
|---|---|---|---|
| KYB and UBO due diligence | Are ownership, licence, products and client markets current? | Which broker entity, owners, controllers and source information will be verified? | Approved entity file, refresh triggers, outstanding conditions and decision owner |
| Client or payer identification | Does the broker know the client and permitted payment owner? | Which payer, beneficiary, merchant or sub-merchant must the PSP identify? | Identifiers, verification result, matching rules and exception workflow |
| Sanctions and PEP screening | Which clients, UBOs, payers and payees are screened? | Which lists, parties and transaction stages are covered? | Match data, review ownership, hold or reject status and lawful information sharing |
| Transaction monitoring | Can deposits, trades, withdrawals, refunds and client profiles be connected? | Can payment velocity, corridors, devices, fraud, returns and nested flows be analysed? | Alert ownership, shared fields, investigation timeline and case outcome |
| Suspicion and regulatory reporting | Which entity has a reporting duty under its regime? | How can facts be exchanged without unlawful disclosure or tipping-off? | Escalation contacts, confidential channel, recordkeeping and legal review |
| Ongoing change review | How are new products, countries, owners and PSP routes approved? | Which changes require renewed underwriting or upstream approval? | Change register, notice terms, reapproval status and deployment gate |
The broker also needs enough transaction data to monitor its own relationship. A net settlement without underlying payer, payee, country, amount, currency, purpose, timestamps and unique references may be operationally convenient but insufficient for client-ledger reconciliation or risk investigation. Confirm data availability before signing, not after an alert occurs.
Compare settlement, reserves, chargebacks, refunds and FX on one basis
Commercial comparison should begin only after legal and operational fit. Two offers cannot be compared from a transaction percentage alone. Define every charge, the base on which it is calculated, the currency and conversion point, tax treatment where applicable, settlement availability and the effect of reserves or negative balances.
| Contract item | Questions to put to every provider | Operational test |
|---|---|---|
| Settlement | Which event starts the timetable: authorisation, capture, scheme settlement, provider receipt or cleared funds? | Reconcile provider availability to bank credit and client ledger without assuming one universal cycle |
| Settlement currency and FX | Where does conversion occur, which rate or benchmark applies, and what spread or markup is added? | Recalculate sample conversions and identify all intermediate currency changes |
| Transaction and payout fees | Which fixed, variable, cross-border, method, payout or minimum charges apply? | Model the actual country, currency, method and transaction-size distribution |
| Refunds and reversals | Who initiates and funds them, which fees are retained, and where does money return? | Test full, partial, duplicate and failed-payment scenarios |
| Chargebacks and retrievals | Who receives notices, owns evidence, meets deadlines and bears losses or scheme charges? | Run a dispute from notification through evidence, decision and accounting entry |
| Rolling or fixed reserve | How is it calculated, held, changed and released, and does set-off or collateral apply? | Track each reserve movement separately from available settlement and client balances |
| Limits and reviews | What transaction, balance or velocity limits apply, and what triggers renewed underwriting? | Stress-test launch, growth and seasonal scenarios without exceeding approved scope |
| Suspension and termination | What events permit a hold, freeze or exit, what notice applies, and when are remaining funds and data released? | Model the cash, client-service and reconciliation impact of an immediate restriction |
Reserve levels, settlement timing, fees and acceptance decisions are provider- and contract-specific. Do not build the business plan on an advertised best case. Use written terms, model expected and stressed scenarios, and identify which provisions the provider may change after risk review.
Review integrations, reconciliation and data security
The technical review should connect checkout or transfer initiation to the broker’s client ledger, payment ledger, bank statement and general ledger. Require stable transaction references, timestamped status changes, gross and net settlement data, fee and FX fields, reserve movements, refund and chargeback identifiers, and a documented correction process.
APIs and webhooks should be tested for authentication, access control, duplicate requests, replay, delayed messages, partial failure, idempotency and version change. A provider dashboard is not a substitute for exportable records. Confirm statement formats, data retention, audit logs, read-only access, historical export and the ability to retrieve records after termination.
Where card data is involved, map responsibilities under the applicable PCI DSS arrangements among the broker, gateway, acquirer and other processors. A hosted payment page or tokenisation can change technical scope but should not be assumed to eliminate every security, privacy or governance duty. Confirm encryption, key and credential management, vulnerability response, penetration testing evidence, breach notification, data location, sub-processors and cross-border transfer requirements.
The contract should allocate incident communication without preventing either party from meeting legal or regulatory duties. Operational and security reporting imposed on a PSP by its regulator does not automatically create an identical report for the broker, so obtain the evidence and notification rights that the broker actually needs.
Where an EU financial entity falls within the Digital Operational Resilience Act, using an ICT provider does not transfer the financial entity’s regulatory responsibility. Relevant risk management and contracts may need to cover service scope, data access and return, incident assistance, regulatory cooperation, termination rights and a documented, tested exit plan. DORA is a specific EU regime, not a universal contract law for every broker or PSP, but its principles are useful when testing critical payment dependencies.
Design redundancy, incident response and an exit plan
A second PSP can reduce reliance on one provider, acquirer or sponsor bank, but it is not a guarantee of continuity. Two front ends may depend on the same bank, processor or card-acquiring chain. Redundancy must therefore be mapped to the underlying dependency, and both routes must be approved for the intended products, countries and funds.
Before launch, obtain clear answers to these continuity questions:
- Which sponsor bank, acquirer, processor, cloud provider, local payout partner and material sub-contractor support the service?
- Which ownership, licence, product, geographic or upstream changes must be notified to the broker?
- What are the incident contacts, severity levels, notification process and tested recovery objectives?
- Can pending payments, refunds, chargebacks, reserves and negative balances be reconciled during an outage or exit?
- How and when can transaction, KYC and accounting data be exported in a usable format?
- What happens to remaining funds, safeguarding records, credentials and client communications after termination?
- Can the broker move approved flows to another route without changing the client counterparty or breaching client-money rules?
Upstream banking risk should be monitored but not confused with the full PSP-selection exercise. Our guide to why banks reject forex brokers explains the entity, market, transaction and control gaps that can also affect a PSP’s bank relationships.
A practical PSP decision and implementation sequence
Do not create an artificial “official score”. Use evidence statuses such as confirmed, evidence pending, not applicable and incompatible. A critical incompatibility in permission, product acceptance, client-money treatment or legal entity should not be hidden by a low fee.
- Define each use case: separate operating payments, client collection, acquiring, payouts, conversion and settlement.
- Map entities and funds: identify payer, payee, broker counterparty, account holder, beneficial owner and every intermediary.
- Verify permissions: cross-check legal entities, registers, services, agents, branches, countries and current status.
- Confirm written fit: obtain product, client, country, currency, payment-method, marketing and limit approval for the actual model.
- Resolve fund protection: test PSP safeguarding separately from broker client-money and deposit-protection questions.
- Allocate controls and data: document KYC, sanctions, fraud, monitoring, reporting, reconciliation, privacy and security responsibilities.
- Compare complete contracts: model settlement definitions, FX, all fees, reserves, refunds, disputes, limits, suspension and exit.
- Test before scaling: run successful, failed, duplicate, refund, chargeback, payout, outage and reconciliation scenarios.
- Approve and monitor: document the decision, conditions, owners, review dates, change triggers and contingency route.
Onboarding has no reliable universal duration or success rate. Timing depends on the broker entity, licence, UBOs, products, countries, expected transactions, funding evidence, provider and upstream reviews, contract negotiation and technical implementation. A long review does not imply approval, and a short estimate is not a commitment.
Monitor the PSP after go-live
Selection is not a one-time procurement event. Reconcile transactions and safeguarding or settlement balances, review fraud and disputes, track service incidents, test user access, and compare actual countries, currencies, methods and volumes with the approved profile. Material changes to the broker, provider, sponsor bank, acquirer, product or flow should trigger reassessment and any notice required by law or contract.
Provider oversight should connect to the broker’s wider governance, regulatory reporting, outsourcing, capital, client-money and change-control programme. See our ongoing forex licence compliance checklist for that broader operating framework.
Frequently asked questions
What is the difference between a PSP and a bank?
PSP is a broad functional term that can include payment institutions, EMIs, acquirers and processors. A bank has specific permission to accept deposits and provide banking services. Verify the actual legal entity and permission rather than relying on the brand or interface.
Can an EMI account replace a forex broker’s bank account?
Not automatically. An EMI may issue electronic money and provide permitted payment services, but the balance’s legal nature, safeguarding, banking structure and suitability for operating, capital or client-money functions must each be verified.
Does a regulated PSP necessarily accept forex brokers?
No. Regulation confirms only the relevant entity and authorised or registered scope. Product acceptance also depends on countries, clients, payment methods, upstream partners, contract terms and the provider’s risk policy.
Is PSP safeguarding the same as deposit insurance?
No. Safeguarding is a statutory or contractual method for protecting defined funds, while deposit insurance depends on the actual bank, account holder, currency, records and legal eligibility. A non-bank payment balance should not be described as an insured bank deposit without verification.
Is a payment gateway the same as a merchant acquirer?
Not necessarily. A gateway may only transmit or process payment data. A merchant acquirer contracts for acceptance and processing so funds can be transferred to the merchant. The provider chain and legal responsibilities should be identified separately.
Can client deposits pass through the broker’s operating account before reaching a PSP?
There is no safe global answer. The broker’s licence, client-money definition, permitted institutions, account designation and segregation rules determine the allowed route. A promise to move the funds later does not replace that analysis.
Is using two PSPs always safer?
No. A second provider may reduce one operational dependency, but both routes can share an upstream bank or processor and multiple providers add reconciliation, AML, data and contract complexity. Redundancy should be tested against the underlying dependencies.
How long does PSP onboarding take for a forex broker?
There is no reliable universal period or approval rate. Timing depends on the entity, licence, UBOs, products, countries, transaction model, evidence, provider reviews, contract negotiation and technical integration, and completion does not guarantee acceptance.
Discuss Your Licensing and Business Needs
Tell us what you need and our team will contact you shortly.