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.
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.
Tell us where you send money and in which currencies, 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.
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 beneficiary is created once, with the account details the destination corridor expects.
ReadyThe item is created against the saved beneficiary, in the currency the payment is being made in.
PendingBeneficiary and payment are screened. Approvals sit here so nothing goes out without release.
Waiting for approvalThe payment is routed onto the rail that fits the destination, SEPA in the SEPA area, SWIFT beyond it, internal between Fenryx accounts.
ProcessingThe item is followed to Finished on the platform, so the answer to "where is it?" is on screen.
In flightFunds land at the receiving side. Timing depends on the corridor and the rail.
SettledMoney the company already holds in a currency balance is earmarked against a saved recipient, released by whoever is allowed to send it, and carried to the receiving institution by the rail that reaches the destination. None of it changes hands off the platform: it leaves a balance you can see and arrives against details somebody entered once.
Two things decide the cost on the way out: the currency it leaves in, and the rail that carries it. Send from a balance already holding the invoiced currency and no conversion happens at all. Send from a different balance and a conversion runs first, with the rate and the cost shown beside each other before anyone confirms, so the total approved is the total that leaves.
Timing depends on where the money is going. A payout into a euro account inside the SEPA area does not behave like one crossing a correspondent chain, so rather than quote hours we attach a status to the payout and keep it current until it settles. When somebody asks where the money went, the answer is a screen rather than a phone call, and the same record is what the period is reconciled against 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.
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.
| 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.
Payout limits are set at onboarding and reviewed against real activity, so how much money an account can send in a single payout, or across one run, follows what the business actually does rather than a published cap. When an unusually large payment is coming, tell us before you send it: the limit gets reviewed against the account instead of the money stopping on the day it matters.
Corridor coverage is confirmed for your account, because the rails that reach some destinations are narrower than others. Ask before you build a process around a corridor and we will say plainly whether the platform can send money there. If it cannot, that answer arrives up front rather than as a payout that fails after the funds have already left.
A payout comes back when the beneficiary details do not match what the receiving institution expects. The money returns to the balance it left from, usually minus whatever the correspondent chain charged to handle it, and the status on the payout changes rather than going quiet, so you hear it from the platform instead of from the person still waiting to be paid. Correct the recipient once, then send it again from the saved beneficiary.