WHAT AN ERP-TO-ERP PAYMENT LOOKS LIKE IN CANADA. AND WHY YOUR COMMERCIAL MEMBERS WILL EXPECT IT BY 2027.
A practitioner's walkthrough of the six-step flow that turns an invoice approval into a fully reconciled payment across two different credit unions. With the rails, APIs, and data layers named.
Part 1 of this series made the case that open banking and payments modernization are one shift, not two. This article makes that shift concrete.
The headline change is that in the model Canada is moving toward, an invoice approved in one ERP can trigger a payment that settles in seconds across two different financial institutions, with the remittance data already attached, and auto-reconciles inside the supplier's ERP without anyone touching a portal (with guardrails and controls in place).
For Canadian credit unions, that's not a hypothetical. The Real-Time Rail launches in waves starting Q4 2026. Phase 2 of the Consumer-Driven Banking Act, which adds payment initiation through regulated APIs, is targeted for mid-2027. ISO 20022 is already the messaging standard on Lynx and will be on RTR from day one. The technical capability for ERP-to-ERP payments will exist inside Canadian banking infrastructure within 18 months.
This article walks through what that flow looks like end-to-end, what each layer requires, and what changes when a credit union's commercial member can move money this way.
This is for the technology leaders inside Canadian credit unions who already understand the strategic argument and are now trying to plan the architecture against it.
The Bottom Line
An ERP-to-ERP payment is a six-step flow: invoice approved in the buyer's ERP, payment triggered via API, processed by the buyer's credit union, moved across payment rails, received by the supplier's credit union, posted back to the supplier's ERP for auto-reconciliation.
The flow requires three technical layers working together: regulated APIs (the open banking framework), real-time settlement (the Real-Time Rail or Lynx, depending on value), and structured data (ISO 20022 messaging).
Most credit unions today have some pieces in place, particularly ISO 20022 on Interac Instant - Receive. Few have the integration layer that exposes payments as APIs to ERP vendors and commercial members.
The competitive implication is direct. Approximately 45% of Lynx transactions are CAD $10,000 or less, which puts a large share of current business payments in the natural migration path to RTR. Credit unions that don't make their RTR participation reachable from inside ERP workflows will see commercial payment volume continue to flow toward fintechs and the Big Six.
The work that determines reachability happens in three places at once: the API integration layer, the back-office posting and reconciliation infrastructure, and the commercial team's go-to-market approach. This is one program, not three.
1. The Flow At A Glance
The rest of this article walks through each step in the diagram. To keep the example concrete, we'll follow a single transaction: Buyer Inc. is a manufacturing company that has just received an invoice for CAD $47,500 from Supplier Inc., a logistics provider. Both companies bank with Canadian credit unions, but with different credit unions. Both run modern ERP systems.
Today, that payment would most likely involve an EFT batch initiated by Buyer Inc.'s AP team, settled overnight, with Supplier Inc. matching the deposit to the open invoice manually the next morning. In the world this article describes, the same transaction happens in seconds, end-to-end, with no human in the middle.
Step 1: The Buyer’s ERP Triggers The Payment
The starting point is an event inside the buyer's ERP. An AP clerk at Buyer Inc. approves the invoice for payment, and a "Payment Triggered" event fires inside the ERP. That event is the actual originator of the payment, not the AP clerk and not a person logging into a banking portal later.
This is the first place the new model breaks from current practice. In the current world, the ERP produces a payment file, somebody downloads it, somebody else logs into a banking portal, and the file gets uploaded for batch processing. The ERP triggered the workflow, but it didn't trigger the payment.
In the new model, the ERP triggers the payment directly. The "Invoice Approved" → "Payment Triggered" → "Payment Initiated" sequence happens inside the ERP and the credit union's API, without leaving software. The AP clerk's job is to approve the invoice, not to manage the mechanics of how it gets paid.
That changes what the credit union has to expose. The buyer's credit union has to be reachable from inside the buyer's ERP in a way that doesn't require a portal, a file, or a separate human action. This is the API integration layer, and it's where most credit unions have the most work to do.
Step 2: The API integration layer connects ERP to credit union
The API integration layer is the connective tissue between the buyer's ERP and the buyer's credit union. It's a secure API connection that lets the ERP submit a payment instruction, receive an acknowledgement, and get back a payment status, all programmatically.
Under the Consumer-Driven Banking Act, this layer is built to a single technical standard. The Financial Data Exchange (FDX) API has been identified as the expected standard, and credit unions including Servus are already building to it. The accreditation process for third parties (ERP vendors, fintechs, integration platforms) sits on top of the technical standard, so a payment instruction coming through the API has a verifiable identity at both ends.
What this looks like in practice is straightforward but architecturally meaningful. The buyer's ERP calls a payment initiation endpoint exposed by the buyer's credit union. The payload is structured: payer account, payee account or alias, amount, currency, purpose code, invoice reference, remittance information. The credit union authenticates the call, validates the consent that authorizes the ERP to initiate payments on the member's behalf, and accepts the instruction.
The new word in that paragraph is consent. In the current world, the buyer's authority to initiate the payment is established once, when they log into the portal. In the new world, consent is a persistent, scoped, revocable artifact that lives in the credit union's API infrastructure. The ERP can initiate payments on the member's behalf because it has explicit, traceable authority to do so. That consent is what makes the payment auditable and revocable later, and it's also what makes the whole flow accreditation-compliant.
Considering how your payments architecture connects to your API and consent strategy? 2Oaks helps credit union leadership teams work through these decisions through our Executive Technology Advisory practice.
Step 3: The Buyer's Credit Union Processes The Payment
Once the credit union has accepted the payment instruction, the work inside the institution looks like a compressed version of what a credit union does today, but with no time to be slow.
Six things happen in order, and they happen in milliseconds. The credit union authenticates the request and validates the consent. It runs the payment through risk and fraud controls (more on this in the next section). It validates that funds are available and reserves them. It posts the debit to the buyer's account on the ledger. It generates the payment message in ISO 20022 format (with enriched payment details). It routes the payment to the right rail.
The routing decision is the part most credit unions haven't had to think about yet. The buyer's credit union has to choose, on a per-transaction basis, whether the payment goes via Lynx (for high-value, time-critical payments), via the RTR (for instant retail and SMB payments), or via Interac e-Transfer (the consumer-friendly rail that for most credit unions will be the access path to RTR at launch).
The choice isn't always obvious. Lynx has no transaction limit and is the natural rail for very large transactions. RTR is irrevocable, settles in seconds, and uses ISO 20022 from day one. Interac e-Transfer caps at CAD $25,000 per transaction and will inherit RTR's settlement infrastructure once Central 1 and other connectors go live in their wave. The CAD $47,500 in our worked example sits right in the middle: too large for Interac e-Transfer at current limits, too small to need Lynx urgency, and a natural fit for the RTR.
The reason this matters is because routing decisions made one transaction at a time, by software, will need to be auditable, defensible, and aligned with the member's expectations. That logic has to live somewhere, and most credit unions don't yet have a place to put it.
Step 4: The Payment Rails Move The Funds
This is the layer that gets most of the press coverage, and is the layer that requires the least new work from credit unions specifically. The infrastructure is being built by Payments Canada. The credit union's job is to connect to it and operate inside its rules.
The three Canadian rails that matter for ERP-to-ERP payments:
Lynx is the high-value, time-critical rail. It's a real-time gross settlement system, which means every transaction settles individually with finality. It replaced LVTS in 2021 and completed its full ISO 20022 migration in November 2025. There's no transaction limit, and approximately 45% of current Lynx transactions are CAD $10,000 or less. Those smaller transactions are the natural migration target for the RTR.
The Real-Time Rail is the new instant rail, with first participants going live in Q4 2026. It's irrevocable, settles in seconds, operates 24/7/365, and uses ISO 20022 messaging from day one. Fraud controls are built in as core features, not added later: a fraud scoring engine, Confirmation of Payee, and integrated fraud reporting. Most credit unions will connect via Central 1 through the Interac e-Transfer pathway rather than directly.
Wires (running on Lynx) and EFT (running on the ACSS, the Automated Clearing Settlement System) round out the picture. EFT is the batch rail that still moves most pre-authorized debits, direct deposits, and bill payments. It will continue to operate, particularly for high-volume recurring transactions where speed doesn't matter and batch economics do.
A practitioner caution worth naming. Some institutions are pursuing ISO 20022 compliance at the messaging-standard level while their core systems strip the enriched payload before posting. The institution can technically claim compliance because it can send and receive the standard messages, but the structured remittance data — invoice references, purpose codes, party identifiers — never makes it into the ledger or out the other side. For a domestic wire or batch payment, this is a workaround that mostly works. For an ERP-to-ERP payment, it breaks the model. The receiving ERP can't auto-reconcile what the receiving credit union didn't preserve. Anyone evaluating their core's ISO 20022 readiness should ask not just whether it can process the messages, but whether it preserves and surfaces the enriched data end to end.
In our worked example, Buyer Inc.'s credit union routes the CAD $47,500 to the RTR. The payment message contains the full ISO 20022 payload: invoice number, purpose code, party identifiers, remittance data (this is important for automated reconciliation). The rail moves the funds to Supplier Inc.'s credit union. Settlement is irrevocable in seconds.
Step 5: The Supplier’s Credit Union Receives And Posts
The receiving side of the transaction has its own work to do, and it's the work that most credit unions haven't yet thought through. Receiving payments will be mandatory for every RTR participant once they gain access, even if they choose not to offer outbound initiation in the first phase.
When the payment message arrives at the supplier's credit union, the institution has to: authenticate the inbound message, validate it against fraud controls, post the credit to Supplier Inc.'s account on the ledger, generate a confirmation, and notify Supplier Inc. that the payment has arrived.
All of this happens in seconds, around the clock, with no human in the loop. That's the constraint most institutions underestimate. A credit union that runs batch posting overnight or has a back-office reconciliation process tied to business hours may find that "receiving payments is mandatory" means rebuilding parts of its operations.
This is the work the article in Part 1 referred to as "getting the back office ready for real-time." It's least visible, most likely to be deferred, and ultimately decides whether the new front-end capabilities function at all.
Hidden inside the core is where most of this work lives, and most of it is in the ancillary systems and integrations that surround the core, not in the core itself.
Step 6: The Supplier’s ERP Auto-Reconciles
The final step closes the loop and is where the productivity gain becomes obvious to the supplier's finance team.
The supplier's credit union sends a payment confirmation through its own API integration layer back to Supplier Inc.'s ERP. The message includes the full ISO 20022 payload: amount, sender, invoice reference, purpose code, and remittance data. Supplier Inc.'s ERP matches the payment against the open invoice automatically. The invoice is marked paid. The AR ledger updates. Cash flow projections update.
In the current world, this is the step that takes time. Someone in Supplier Inc.'s AR team logs into the bank, downloads the day's transactions, opens the ERP, finds the matching invoice, and reconciles them manually. For small organizations, that's manageable. For larger organizations with hundreds of daily incoming payments, it's an entire job function.
In the new world, the matching happens because the data needed to do it travels with the payment. ISO 20022 makes this possible at the protocol level. The credit union's job is to make sure the payload that came in over the rail makes it back out through the API layer to the ERP, unaltered.
That's why ISO 20022 matters so much. Speed of settlement is the part that everyone talks about. Data structure of the message is the part that drives the productivity gain.
What’s Different From How Payments Work Today
Reading the six steps end to end emphasizes the contrast with current practice.
Today, a typical B2B payment between two Canadian businesses banking with different credit unions involves: an ERP that produces a file, an AP person who logs into a portal and uploads the file, a batch that processes overnight, an EFT that settles the next business day, an AR person who matches the deposit to the open invoice manually, and a delay of one to three business days end-to-end. Remittance data, where it exists, travels separately from the payment, often by email or in the memo field. Complexities also arise when NSF occurs on payments.
In the new model, the same transaction is: an ERP event, an API call, real-time risk and ledger processing, instant settlement, a return API call, and auto-reconciliation. End-to-end in seconds. Remittance data travels with the payment in structured form.
This is much more than an incremental change. It's a different category of transaction.
What This Requires From Credit Unions
For a Canadian credit union to be a participant in this model, four pieces of work have to come together. They don't have to be sequential, but they do all have to happen.
API integration layer. A credit union has to expose payment initiation as a regulated API, built to the FDX standard, with consent management, accreditation handling, and rate-limiting baked in. Most Canadian credit unions don't yet have this layer. Building it is an 18-month program at the fast end and a multi-year program at the slow end, depending on core and integration platform readiness.
Real-time back office. Posting, reconciliation, liquidity management, and fraud monitoring all have to operate in real time, 24/7. This is the work that determines whether the API layer can function at all. A modern API in front of a batch-oriented back office produces a slow, expensive credit union that pretends to be a fast one.
Routing logic and rail participation. The credit union has to be a participant in the rails the payment can use (most credit unions will connect to RTR through Central 1 and Interac e-Transfer; Lynx participation is direct only for larger institutions). It also has to have a defensible routing rule for which rail a given transaction uses. That logic lives in the payments platform, not in human judgment.
Commercial model and ERP relationships. The credit union has to have something to offer commercial members and their ERP vendors, and someone in the credit union has to know how to have that conversation. This is the part that most credit unions treat as a future problem and discover too late is a current one. ERP vendors are choosing their integration partners now.
Working through a payments and open banking roadmap together? 2Oaks provides strategic advisory and planning for credit unions running these as one program rather than two.
What This Looks Like From Here
The six-step flow in the diagram is more than a forecast. The infrastructure for every step exists in Canadian banking today, with Phase 2 of CDBA scheduled for mid-2027 to complete the picture. By the time the Canadian credit union sector finishes its current wave of consolidation, this is going to be how mid-market B2B payments work.
The credit unions positioned to compete in that world are the ones treating ERP-to-ERP payments as the design target, not a possible future feature.
"Having implemented Interac Instant – Receive with Temenos Payments Hub for a credit union client, I've seen what shifts when payments stop being a back-office wait. For small and medium-sized businesses, working capital tied up in reconciliation cycles is real money. The credit unions that get this architecture right will find their commercial members notice the difference long before the rails do."
~ Andrew Mills
This is the second article in a series on the intersection of open banking and payments modernization. Part 1 made the strategic case for treating these as one program rather than two. Part 3 will lay out what credit unions should be doing in the next 12 months.
Working through what ERP-to-ERP payments mean for your credit union's architecture and commercial roadmap? Talk to a practitioner.
FURTHER READING
Payments Canada: About the Real-Time Rail. The official Payments Canada overview of how the RTR works.
Bank of Canada: Settlement Account Access Policy for the Real-Time Rail. The participation rules and prudential requirements for direct RTR access.
Central 1: Understanding the RTR. The clearest view of how most credit unions will connect to the RTR.
FAQs
Why does the diagram show "RTR / EFT / Wires" as if they're peers when they serve different purposes?
They're not peers. Each is a distinct Canadian payment rail with different value, speed, and use case characteristics. Wires (Lynx) handle large-value, time-critical payments with no transaction limit. EFT (ACSS) handles low-value batch payments like payroll and direct deposits. RTR handles instant, data-rich retail and SMB payments, with the first phase going live Q4 2026. The credit union's routing logic chooses among them on a per-transaction basis based on value, time-sensitivity, and member instructions.
Sources: Bank of Canada, Payment systems oversight; Payments Canada, Real-Time Rail overview.
Will all credit unions connect to the RTR directly, or through Central 1?
Most Canadian credit unions will connect to the RTR through Central 1, via the Interac e-Transfer pathway. Direct RTR participation requires meeting the Bank of Canada's settlement account access requirements, which include prudential standards, payment capacity estimates, and an agreement with the Bank governing the settlement account. For most credit unions, the Central 1 connection path is the practical option, with the RTR settlement happening behind the scenes.
Sources: Central 1, Understanding the RTR; Bank of Canada, RTR settlement account policy.
What's the transaction limit on the Real-Time Rail at launch?
Payments Canada has not published a final transaction limit for the RTR at launch. For comparison, Interac e-Transfer (which most credit unions will use as the connection path) currently caps at CAD $25,000 per transaction, and Lynx has no transaction limit. The RTR is being designed for higher business-payment values than Interac e-Transfer historically supported, and approximately 45% of current Lynx transactions are CAD $10,000 or less, making them natural migration candidates. Credit unions should plan for RTR to accommodate at least mid-six-figure business payments, with the specific limit set by Payments Canada rules and by individual financial institution policies.
Sources: DC Group, Real-Time Rail launch overview; RedCompass Labs, preparing for the Real-Time Rail.
How can 2Oaks help a credit union prepare for ERP-to-ERP payments?
2Oaks works with credit union leadership teams on the architectural decisions that determine whether an institution is reachable inside member ERP workflows. Our partners have been in the CIO and CTO chair at Canadian credit unions, led core banking modernizations and ISO 20022 implementations, and understand the relationship between the API integration layer, the back-office posting infrastructure, and the commercial banking model. The most common engagements: strategic readiness assessment, executive technology advisory, and program leadership for institutions running open banking and payments modernization as one program.
Get in touch. Talk to a practitioner.
ABOUT 2OAKS
2Oaks emerged from deep within the banking sector, where our founders personally navigated the challenges of core system modernization. This hands-on experience shaped our unique approach to technology consulting -one that combines technical expertise with practical wisdom. We're not your typical consultancy. As a vendor neutral partner, we work exclusively for our clients' interests across banking, financial services, retail, and public sectors.
What sets us apart is our commitment to co-creation and knowledge transfer. We work alongside your team, ensuring that our solutions aren't just implemented but truly integrated into your organization. Our lean, efficient approach eschews unnecessary complexity in favour of practical, results-driven outcomes. Whether you're facing a system transformation, technology upgrade, or strategic shift, reach out to 2Oaks to discover how our principled, authentic approach can drive your success.