A prop firm with sixty affiliates spread across fourteen countries runs its monthly payout day through a normal business bank. Each payment is an international transfer. Each one carries a sending fee, an intermediary deduction somewhere in the chain, and a conversion done at whatever rate the bank felt like publishing that morning. The affiliate who was promised 400 receives 371 and opens a ticket. Multiply by sixty and the payout run costs more in fees and support time than the smallest affiliates earn.
That specific problem is what Wise Business is good at. It is worth being precise about the boundaries of that claim, because the account is also asked to do things it cannot legally do.
What the account is
Wise Business is the company version of the multi-currency account described in Wise for traders. It gives the company balances in a range of currencies and, in several of them, local account details: an account and sort code arrangement in sterling, an IBAN in euro, a routing number in dollars, and others depending on the market. Money can arrive as a domestic payment in each of those currencies rather than as an inbound international wire, which removes both the fee and the delay.
Legally it is an electronic money institution in most markets, so funds are safeguarded rather than covered by a deposit guarantee scheme. That distinction is not academic for a company holding a float, and it is the same distinction discussed in the EMI licence. Safeguarding is a real protection with a different failure mode from deposit insurance, and a treasurer should know which one applies to each pot of money.
The features a trading firm actually uses
- Batch payouts. A spreadsheet of recipients uploaded and approved once, rather than sixty separate forms. This is the feature that pays for the account on its own if you run affiliate or contractor payments.
- API access. Payments triggered from your own systems, so an approved payout in your back office becomes a real transfer without anyone retyping an IBAN. Retyping IBANs is where payment errors come from.
- Multiple users with roles. Someone prepares, someone else approves. Any firm where one person can both create and release a payment has a control problem regardless of how much they are trusted.
- Local details for receiving. Vendors, partners and payment processors settling to you in their own currency, without an inbound wire fee on every arrival.
- Accounting export. Transactions flowing into the bookkeeping system, which matters more than it sounds when the auditor asks you to reconcile a year of small cross-border payments.
The payout workflow is the piece worth designing carefully. Approval, evidence of who authorised it and reconciliation against the request all belong in the system that holds the client record, with the payment rail underneath as execution. For a prop firm that means the payout queue lives in the prop firm CRM and the transfer is the last step, not the first. The comparison of rails available for that last step is in payout rails compared.
What onboarding will ask
Every payment institution treats financial services as a higher risk category, and trading firms sit inside it. Expect questions about the regulated activity you carry out, the licence or registration behind it, the ownership structure up to the beneficial owners, the countries your customers are in, and the volumes you expect to move. Vague answers extend the review; precise answers with documents attached shorten it.
Acceptance is not guaranteed. Providers publish acceptable use policies restricting certain categories of business, and those policies change. A firm that reads the current policy before applying, and describes its activity accurately in the application, gets a clean decision. A firm that describes itself as "software" when it operates a brokerage gets an account that is closed six months later during a review, usually at the least convenient moment. What the onboarding team is doing is the corporate mirror of client due diligence, covered in KYB for firms.
Never let operational float and client money share an account. Client funds held under a licence must sit where your regulator's client asset rules require, with the right acknowledgements in place, and the principle is set out in client fund segregation. This is the line that ends firms when it is crossed.
Where it stops working
Three limits show up as a firm grows. The first is concentration: a single provider holding the entire operating float means a single review can pause payroll. Keep a second rail live and tested, even if it costs more per transfer.
The second is client-facing payments. Sending withdrawals to hundreds of clients through a business account is a different activity from paying suppliers, and depending on your licence and jurisdiction it may need a payment provider built for that purpose with the reporting to match. Look at that properly rather than growing into it by accident, using the framing in mass payouts explained.
The third is currencies the network does not cover well. Not every corridor has local details behind it, and where it does not, the transfer becomes an ordinary international payment with ordinary international costs. If you pay recipients in markets with local rails outside the major networks, check corridor by corridor rather than assuming the whole map is covered. The underlying difference between the two kinds of transfer is in SEPA vs SWIFT.
The pragmatic setup
Most small brokers and prop firms end up with a conventional bank account for the corporate relationship and anything requiring a bank reference, a business account like this one for cross-border operational payments, and a separate arrangement for client money that is dictated by the licence rather than chosen for convenience. Three lanes, clearly labelled, with nobody moving money between them without a documented reason.
That structure survives an audit. Anything simpler tends not to, and the moment you discover it does not is the moment a regulator or an auditor is already asking questions.
"Every firm I have watched get into trouble on payments started the same way: one account doing three jobs, because it was easier in the first month."
— Roman Onta, Executive Director, SINGUARD
Key Takeaways
- Local account details in several currencies turn inbound and outbound international wires into domestic payments in the corridors they cover.
- Batch payouts, API access and separate prepare and approve roles are the features that pay for the account in a trading firm.
- Describe your regulated activity accurately at onboarding, because an account opened on a vague description is an account closed during review.
- Operational float, client money and client-facing payouts are three separate lanes, and merging them is the failure that ends firms.
Frequently Asked Questions
Can a broker hold client funds in a Wise Business account?
No. Client money held under a financial services licence must sit in accounts that satisfy the regulator's client asset rules, which specify the type of institution and the acknowledgements required. A business account at an electronic money institution is operational money for the firm, and mixing the two is a serious compliance failure.
Will Wise accept a forex broker or prop firm as a customer?
It depends on the activity, the jurisdiction and the current acceptable use policy, which restricts several categories of regulated and high-risk business. Apply with your licence details, ownership chart and expected payment volumes ready, and expect questions about which countries your customers are in.
How does Wise Business handle paying many recipients at once?
A spreadsheet of recipients can be uploaded and approved as one batch, and an API allows the same payments to be triggered from your own systems. Both routes still run each payment through screening, so a single recipient can be held for review while the rest of the batch completes.