Paying many recipients is a workflow, not a keystroke. Manage payees, statuses, limits and reconciliation on one platform in Canada, with the record of every payment kept beside it.
Platforms, marketplaces, partner programmes and contractor networks share the same pattern: the same list of people to pay, on a rhythm, in currencies the counterparties invoice in. Most of the trouble does not come from moving money. It comes from managing the list and the record.
Recipients are re-keyed each cycle, and the same person appears twice because two teams keep their own lists.
Reconciliation is manual: last month's export lost the reference each payment carried, so the match against invoices is done by hand.
Conversion cost is folded into the rate rather than shown beside it, so the real payment cost only appears after the fact.
Balances sit across separate providers, and nobody can say what is available to pay out from one screen.
Payments leave with no visible status, so each time somebody asks where a payment is, the answer is a guess.
Approvals are ad hoc, held in email, and never end up beside the payments they authorise.
A mass payout is a payment run in which a company pays many recipients over a short window rather than one at a time. What makes it a payout, whether one or many, is the direction: money leaving the company against details belonging to the party being paid. What makes it a mass payout is the shape of the list behind it.
Underneath, the financial layer is the same as a single payment. Each item has a recipient, a set of account details, a currency, an amount, a rail it travels on (SEPA within the SEPA area, SWIFT beyond it, internal between Fenryx accounts), and a status that follows it from pending to finished. What differs is the density: hundreds of items, one operator, and a need to see the whole run and each item within it. When those recipients sit outside the country the account is held in, the same run is also a set of international payouts.
Fenryx is a digital finance platform and payment account provider. For mass payouts, the posture is deliberately narrow: hold funds in the currencies you already work in, keep the recipient list where the payments themselves live, and let a payment run against that list move through approval, release and reconciliation on the same platform. The point is to reduce fragmented payment workflows, not to replace the bank behind them.
Rails available for outgoing payments are the ones the platform runs. Coverage of any given corridor is confirmed at onboarding rather than promised across the board. Where volume calls for programmatic integration or file-based upload, terms are discussed as part of onboarding and shaped to the account rather than published as a general feature. Companies weighing the wider picture usually read this beside global payouts and the cross-border payments solution.
The company applies online and sends documents remotely. Every account opens through a KYB review, and accounts stay under ongoing screening once they are live.
Balances in the currencies the business earns and pays in, so payments to sellers or contractors leave the balance holding the invoiced currency. See multi-currency account.
Details of your own, so platforms, buyers and processors fund the balance from which the outgoing run is paid. See IBAN account.
Payments leave over the rail that fits the destination, with beneficiaries kept for next time and the same reference format across a run.
Each payment moves through Pending, Waiting for approval, Processing and Finished. One user prepares items, another releases them, and nothing goes out without the release.
Detail on each payment, comments and references survive into the export. Periods can be exported for the accounting side, and the export mirrors what the platform holds.
An international seller base paid on a schedule out of the balance holding what the seller invoiced, so a payment does not start with an unplanned conversion. Beneficiaries are kept on the platform; each cycle reuses them rather than re-keying.
Revenue share paid to partners on a set day, each payment carrying the reference that tells the partner which period it covers, and the same reference travelling into the export the finance team keeps.
A monthly run to the same people, saved beneficiaries, a second pair of eyes at release, and the reasons for any held item recorded against it rather than in a side email thread.
Closing the month means matching outgoing payments to invoices and to the balances they left. One platform holds both sides, so reconciliation is a lookup rather than an assembly job across providers.
A platform whose own users are legal entities, paying them out of a Fenryx balance rather than routing each payment through a general-purpose bank. The rails behind it are the same ones described on the cross-border payments platform.
How many recipients, which currencies, and how often. We will confirm what the platform covers for your account before you commit to anything.
Discuss your payout runStill mapping the setup? See accounts for small business or foreign currency accounts.
Tell us who your business pays and in which currencies.
The company, owners and payout profile are verified.
Balances, users, roles and access are configured.
Fund the balance, add or import the recipient list, prepare a run and send it for approval.
Follow each item to Finished; export the period, references intact.
| Item | For your account |
|---|---|
| Transaction fees | Quoted per account, shown before you confirm a payment |
| Currency conversion | Rate and cost shown side by side, not folded into the rate |
| Payout limits | Set at onboarding, reviewed against real activity |
| Currencies and rails | Agreed per account, aligned to who you pay |
| Settlement timing | Depends on the rail and the receiving institution |
Terms depend on the business profile and the payment corridor, so pricing is set at onboarding rather than published as one price list.
Registered legal entities only. We do not open personal accounts, and payments run from a company to its counterparties rather than between individuals.
Eligibility depends on business type and jurisdiction, on where a company pays, and on the outcome of KYB review. Screening applies to the account and its recipients throughout, not only at onboarding.
A summary. See our AML Policy.
A neutral checklist. The right provider is the one whose answers to these questions match how the business actually pays.
Which rails does the provider run, and do they reach the destinations your recipient list already includes?
Can you hold the currencies your counterparties invoice in, so payment does not start with a conversion?
Does each payment have its own status, and does that status live where the payment does rather than in a separate export?
Are beneficiaries kept between runs, and is there one list rather than parallel copies held by different teams?
Can more than one user be required to release a payment, and is that release recorded against the payment itself?
Do payment detail, comments and references survive into the export the accounting side receives?
A mass payout is a payment run in which a company pays many recipients over a short window rather than one at a time. What makes it a payout, whether one or many, is the direction: money leaving the company against details belonging to the party being paid.
Marketplaces settling with sellers, platforms paying partners on a share of revenue, contractor networks paying people on the same day each month, and finance teams closing a period. The common thread is many recipients, repeatable schedules and a need for one record of what was paid.
Yes, within the rails the platform runs. Payments over SEPA reach accounts in the SEPA area; SWIFT reaches beyond it; internal transfers reach other Fenryx accounts. Coverage of a particular corridor is confirmed at onboarding rather than promised across the board. For the corridor-by-corridor view, see international payouts; for the widest destination picture, global payouts.
A payment that does not reach the recipient is returned by the receiving side and appears against the original item in the platform, with the reason attached. The company decides whether to correct the beneficiary details and send again or to close the item; nothing is retried silently.
The legal name of the party being paid and the account details the payment must reach, expressed as an IBAN where the rail expects one and as local details where it does not. Additional information is asked for where the destination or the amount calls for it, in line with standard beneficiary checks. The payment itself leaves a balance you hold — see foreign currency account — while incoming funds arrive on an IBAN account.
Tell us who your business pays, in which currencies, and on what cadence.
Fenryx is operated by Globally United Tech Corporation, a money services business registered with FINTRAC in Canada, Vancouver, BC. Payout availability, currencies and limits depend on business type, jurisdiction and KYB review. Settlement timing depends on the rail and the receiving institution.