An international payout is more than a send: recipient details, currencies, statuses, limits and reconciliation, held together on the same platform the payment leaves from.
Cross-border transfers land after several intermediaries have handled them, and the delay is only visible once the payment is already late on the other side.
Conversion cost is folded into the rate rather than shown beside it, so the real payment cost only appears after the fact.
Different corridors expect different beneficiary details, and a payment sent with the wrong shape of data is returned rather than corrected on the fly.
Exports lose the reference each payment carried, so matching outgoing payments to invoices is a hand job at the close of every period.
Payments leave with no visible state, so each time somebody asks where a payment is, the answer is a guess rather than a screen.
Sign-off happens in email, never lands beside the payments it authorised, and cannot be shown to an auditor months later.
An international payout is an outgoing payment sent from a company to a party outside the country the account is held in. Underneath, the mechanics are the same as any payment out: an instruction is created against saved recipient details, checked by compliance, routed onto a payment rail that fits the destination, and finally settled at the receiving side. What differs across borders is which rail carries it and which data the rail expects.
Two rails cover most international traffic: SEPA reaches accounts in the SEPA area denominated in euros; SWIFT reaches beyond it and works across currencies through a network of correspondents. Internal transfers between Fenryx accounts stay on the platform. A payment travels the one that fits its destination, and its status follows it from initiated through processing to settled, on the same screen the payment was created on.
The same mechanics underpin every outgoing direction we run, whether that is a single supplier payment, a run to many recipients at once, or the broader cross-border payments solution a company operates day to day.
Fenryx is a digital finance platform and payment account provider. For international payouts, the posture is deliberately narrow: hold funds in the currencies the business already works in, keep recipient details where the payments themselves live, and let each payment move through approval, release and settlement on the same platform where the balance sits. The point is to reduce fragmented payment workflows, not to replace the institutions behind them.
Which corridors an account can pay into, and whether volume is served through file-based upload or a programmatic route, is agreed at onboarding and shaped to the account rather than promised as a general feature. What is on offer across the board is the same platform: currency balances, rails, statuses, approvals and exports, wired together so operating outgoing payments is one seat rather than several. Companies whose outgoing side is broader than one corridor usually read this alongside global payouts and the cross-border payments platform.
The company applies online and sends documents remotely. Every account opens through KYB review, and accounts stay under ongoing screening once they are live.
Balances in the major currencies the business earns and pays in, so a payment leaves the balance already holding the invoiced currency. See multi-currency account.
Payments leave over the rail that fits the destination, with the same reference format across a run and beneficiaries kept for next time.
Beneficiaries kept on the platform between runs, with the account details each corridor expects held in the shape the rail needs them.
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.
Invoices settled from the balance already holding the invoiced currency, so a payment to an overseas supplier does not start with an unplanned conversion.
People in different countries paid on a schedule, saved beneficiaries reused each cycle, and a second pair of eyes at release recorded against the payment itself.
Cross-border settlement runs to a seller base spread across corridors, with each item carrying the reference that tells the seller which period it covers. Where the same run repeats every cycle, see mass payouts.
Reconciling outgoing payments against invoices happens on the same platform the payments left from, filtered by status rather than reassembled from separate exports.
Studios, consultancies and agencies whose counterparties sit in more than one country, paid on the same day each month from balances the company already holds. Smaller teams often start from business accounts for small business.
Tell us which countries and currencies your payments need to reach, and we will confirm what the platform covers for your account before you commit to anything.
Discuss your payout corridorsStill comparing? Read global payouts or the cross-border payments solution.
The beneficiary is created once, with the account details the destination corridor expects.
The item is created against the saved beneficiary, in the currency the payment is being made in.
Beneficiary and payment are screened. Approvals sit here so nothing goes out without release.
The payment is routed onto the rail that fits the destination — SEPA in the SEPA area, SWIFT beyond it, internal between Fenryx accounts.
The item is followed to Finished on the platform, so the answer to "where is it?" is on screen.
Funds land at the receiving side. Timing depends on the corridor and the rail.
| Item | For your account |
|---|---|
| Transfer fees | Quoted per account and per rail, shown before you confirm |
| Currency conversion | Rate and cost shown side by side, not folded into the rate |
| Payout limits | Set at onboarding, reviewed against real activity |
| Settlement timing | Depends on the corridor and the rail; no fixed hours are promised |
Terms depend on the business profile and the 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 operational comparison. The right provider is the one whose shape matches how a company actually sends payments, not a claim about either being universally better.
Outgoing payments a company sends across borders to a party outside the country the account is held in. The payment leaves the company against details belonging to the recipient and travels over a payment rail suited to the destination and currency.
A payment is initiated against saved recipient details, checked by compliance, routed onto a rail that fits the destination (SEPA within the SEPA area, SWIFT beyond it), moved to Processing, and finally settled at the receiving side. The platform keeps a status against the payment throughout.
Companies paying suppliers abroad, contractor networks paying people in more than one country, marketplaces settling with international sellers, finance teams reconciling outgoing payments across corridors, and distributed service providers paying counterparties on a schedule. Where the same list is paid every cycle, that is a mass payout; where the destinations span many regions at once, see global payouts.
Timing depends on the corridor and the rail the payment travels. Rather than publish an estimate that may not hold, the platform gives every payment its own status so the answer to "where is it?" is on screen at any moment.
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 funds themselves leave a balance you hold — see foreign currency account — and arrive on an IBAN account when the flow runs the other way.
Tell us which corridors your business pays into and in which currencies.
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 corridor and the rail.