One operating layer for payments coming in, funds held, and payments going out, so cross-border payments are a process your global business runs rather than a series of one-off transfers.
A single cross-border transfer is an event. A cross-border payments platform is the layer that event happens inside: where payments arrive, where funds are held between arriving and leaving, where one currency becomes another, and where every payment instruction is prepared, approved and recorded. The difference matters because a global business does not have one payment, it has a flow of them.
Read that way, a cross-border payments platform is not a faster pipe. It is the operating layer that answers four questions at any moment: which payments came in, what is held and in which currency, which payments are going out, and who authorised them. A transfer service answers none of those the next morning.
Fenryx is a digital finance platform and payment account provider. What follows describes how the platform is put together for a business moving cross-border payments between markets, and what to compare if you are weighing up more than one option.
Most confusion about cross-border payments comes from treating these as one thing. They are not, and knowing which is which decides how a new client's first payment reaches you.
Payments arriving from someone else: a client, a marketplace, an acquirer settling card takings. That needs details of your own to quote, which is what an IBAN account provides.
Third parties cannot pay into a currency balance directly, and expecting them to is the most common reason a first cross-border payment comes back to the sender.
Balances the business owns and funds itself, in the currencies it works in. They are topped up from your own accounts or from what collection brings in, and they are what cross-border payments are ultimately paid out of.
See currency accounts and multi-currency accounts for how balances behave.
Payments leaving to suppliers, contractors and global partners, against details belonging to them. Each payment is funded from a balance, routed over one of the rails below, and tracked to a final status.
The three connect in one direction: collection fills the balances, the balances fund the payments that go out, and every step is recorded against the same profile. A global business that keeps these on three different systems is not running one payment process, it is reconciling three. On a cross-border payments platform they are the same ledger seen from different ends, which is why a new market usually means a new balance rather than a new provider.
Collection sits with one provider and payments out with another, so no single view of the global position exists at any moment.
Conversion happens by moving funds between providers, which turns one decision into three payment instructions and two waits.
References are lost between systems, so reconciling global payments becomes a monthly exercise in matching amounts to invoices by hand.
Nobody can say where a cross-border payment is, because the status lives in an inbox rather than on a screen.
Anyone with the login can send a cross-border payment, because nothing separates preparing a payment from releasing it.
Every new market means a new provider, a new onboarding and one new export format for the finance team to normalise.
On a cross-border payments platform, conversion is a function rather than an errand. Funds move from one balance to another inside the same profile, at the rate shown with the cost beside it, and only once you confirm. Nothing leaves the platform to change currency and come back, which makes conversion a decision your business schedules rather than a side effect of payments arriving.
Convert when the rate in front of you is one you want, not on the day a global customer happened to pay.
The rate and what it costs appear in the summary before you confirm, so nothing about the price arrives later.
Each conversion is a transaction with detail behind it, so it reconciles like any other movement on the account.
What this changes for a global business is the sequence. Without a platform, a cross-border payment often forces a conversion at the moment it arrives and another when it leaves, because the funds cannot sit anywhere in between. With balances in the middle, incoming payments stay as they landed until there is a reason to move them, and the rate you accept is one you looked at. No figures are published here, because the applicable rate and cost are shown to you on screen before each conversion and confirmed in writing for your account.
Cross-border payments travel a scheme, and the scheme decides the shape of the journey. These are the rails the platform uses.
| Rail | What it carries | When it applies |
|---|---|---|
| SEPA | Euro payments across the single euro payments area | Standard euro transfers, in and out |
| SEPA Instant | Euro payments on a scheme that settles outside the standard cycle | Where the scheme is available to both sides |
| SWIFT | Cross-border payments beyond the euro schemes | Where the destination is not reachable on SEPA |
| Internal | Movements between Fenryx accounts | Where both sides are on the platform |
Which rail a given payment uses follows the currency, the destination and the configuration agreed for your account, not a tier you bought. That is worth stating plainly: routing on a cross-border payments platform is a property of the payment, and a platform that markets speed as a package is describing pricing rather than rails. Availability and settlement timing depend on the receiving institution, so neither is published here as a promise, and a new corridor is enabled after review rather than switched on by default.
Every payment carries a status from the moment it is created, so the answer to "where is that cross-border payment" is on a screen rather than in somebody's memory.
Behind each one sits the transaction detail: amount, currency, rail, beneficiary, the comment and the reference it was sent with. That detail is what the export carries into your books, which is the difference between reconciliation as a task and reconciliation as an afternoon. One export covers collection and payments out together, because both flows live on one platform.
For a business with global counterparties this is usually where the value shows up. Cross-border payments are not hard to send; they are hard to account for afterwards, once references have been stripped, currencies have changed and the record sits in three places. A platform that keeps the reference attached from creation to settlement removes most of that work before it starts, and gives your finance team one file instead of a reconstruction project each month.
Who may release payments is part of the platform rather than an office convention.
A user creates the payment, adds the beneficiary and the reference, and submits it. Nothing has moved yet.
An authorised user releases the payment. Until then it sits at Waiting for approval, visible to everyone who needs to see it.
An accountant or auditor reads the account and exports what they need, with no ability to move a single payment.
The business is verified before an account is configured, and the people behind it are identified. Every new account on the platform opens this way.
Clients and counterparties are screened at onboarding and through the relationship against the sanctions regimes that apply to us as a Canadian money services business.
Cross-border payments are monitored while the account is open. A payment may be held for review before release, which is a normal part of the process rather than an exception.
Checks take place on every cross-border payment flow, and no platform or provider can promise their outcome in advance. Eligibility depends on business type and jurisdiction, and a new counterparty or a new market may prompt questions before payments move. Planning for that is more useful than being surprised by it.
This page describes how the platform operates. It is not legal, regulatory or tax advice, and it does not describe the obligations that apply to your own business. Take advice from your own advisers on those.
Accounts are opened for registered legal entities. We do not open personal accounts, so every cross-border payment flow described here runs from a business to its global counterparties.
Beyond that, eligibility depends on business type and jurisdiction, on where a company sends cross-border payments, and on the outcome of KYB review. A new market or a new global counterparty may change what is available on an existing account, which is one reason the configuration is revisited rather than fixed once.
A summary. See our AML Policy.
Seven questions that separate an operating layer from a transfer service, whichever platform or fintech provider is in front of you.
Can third parties pay you directly? If collection needs a separate provider, you do not have one platform, you have two.
Are balances held, or converted on arrival? A platform converting every global payment as it lands has made the timing decision for you.
Is the rate shown before you commit? The cost of conversion should be visible in the summary, not reconstructed afterwards.
Which rails does it actually reach? Ask which schemes are enabled for your account and for the cross-border payments you actually send, not which appear in the marketing.
Do payments carry a status? A platform without one moves every "where is it" question to your support inbox.
Can preparing and releasing be separated? One login that can do everything is a control problem waiting for a bad week.
Does the export match your books? References and comments have to survive into the file, or reconciling cross-border payments stays manual whatever else the platform does.
A transfer service moves one payment and stops. A platform holds the balances either side of it, converts between them, records who approved what, and gives one export covering money in and money out. The difference shows up at month end rather than at the moment of sending.
Collection. It carries details a third party can pay into, which a currency balance does not. Payments are then funded from the balances behind it, so a business that both collects and pays out usually runs the two together on one profile.
Yes, and that is the point of an operating layer. What arrives through collection funds the balances that payments leave from, and both sides appear in the same statuses and the same export rather than in two systems nobody reconciles.
Nothing moves. It sits at Waiting for approval, visible to the users who need to see it, until somebody authorised releases it. A payment may also be held for a compliance check before it goes out, which is part of the process rather than a fault.
No. We describe how our own process works, including the checks that apply to us as a Canadian money services business. What rules apply to your company, in your markets, is a question for your own legal and tax advisers, and nothing here should be read as advice on it.
Balances and routes are added to a profile that already exists, so a new market does not mean a new application. What can be enabled depends on the business, the destination and the review, so it is agreed rather than switched on unilaterally.
Tell us how payments reach your business today, and where they go next.
Fenryx is operated by Globally United Tech Corporation, a money services business registered with FINTRAC in Canada, Vancouver, BC. Availability of currencies, rails and limits depends on business type, jurisdiction and the outcome of KYB review. Settlement timing depends on the rail used and the receiving institution.