An ePayable is a digital accounts payable method that replaces mailed checks with supplier-specific virtual card credentials tied to a vendor payment. It works by issuing a unique card number, expiration date, and CVC after AP approval, then routing reconciliation data back to ERP. In practice, teams use virtual cards for control and traceability, ACH when card acceptance is weak, and checks only as a fallback.
Platform teams usually replace paper checks once payment speed, status visibility, and clean matching become operating requirements, not nice-to-haves. Checks still work in many workflows, but they can become a bottleneck as volume rises and control expectations tighten. If your team is still chasing check status by email, you are already paying the cost of that bottleneck.
Both realities can be true at once. Checks are still common, and the risk tied to them is still material. Federal Reserve business research says checks and cash are still used, though usually less often and often as secondary methods. A 2025 AFP survey summary also reported that 91% of organizations still used checks and more than 75% had no immediate plan to stop. That same summary described checks as the payment method most subject to fraud. AFP separately reported that 63% of respondents faced check fraud in 2024. Because these inputs are survey-based, use them as directional evidence rather than a universal rule for every organization.
That makes this an operating-model decision, not a blanket "go digital" slogan. As payment volume grows, these tradeoffs get harder to ignore. U.S. federal policy language is similarly direct. It describes paper-based payments as creating unnecessary costs, delays, risks of fraud, lost payments, theft, and inefficiencies.
A practical migration path is usually mixed, not absolute. If a supplier can accept card payments, ePayables (virtual cards assigned to specific vendors) are often worth evaluating. If card acceptance is not workable but bank transfer is, ACH is a widely used digital rail and its network volume continued to grow in 2025. If neither rail is workable, checks can stay as an explicit exception. We recommend defining those routing rules before your team starts promising a digital-first rollout.
Evidence quality also varies across market-adoption claims. Some search coverage cites large growth projections tied to unnamed or thinly described studies, so those numbers should not drive your decision. The more reliable test is operational fit: which rail gives you usable controls, clearer payment records, and less ambiguity when finance matches the payment back to the invoice.
Before you expand any rail, verify three basics in your current AP flow. Make sure:
This matters because moving funds electronically without a coherent evidence trail can still leave reconciliation gaps. The strongest case for moving beyond checks is not just digitization, but cleaner proof of what happened, when it happened, and how it ties back to the underlying bill.
We covered this in detail in Building a Virtual Assistant Platform Around Payments Compliance and Payout Design.
An ePayable, often called Virtual Payables, is a digital AP payment method that replaces mailed paper checks with supplier-specific virtual card credentials tied to a vendor payment.
The payment object is simple: a unique card number, expiration date, and CVC generated for that payment intent. In one documented AP flow, the provider generates a unique 16-digit virtual card number for the payment amount. Depending on the program, that setup may be one-time. Some products allow one virtual card account to cover multiple invoices.
On the AP side, the trigger is usually an approved payment file. The core sequence is straightforward:
The real checkpoint is the return path, not just card issuance. Because reconciliation data is part of the flow, make sure you can tie each payment back to the invoice, supplier, and internal payment record. If you cannot trace that path quickly, your team will feel the gap at close and in supplier support queues.
That matters even more when you scale beyond a pilot. ePayables modernize the disbursement rail, but coverage is not uniform. Supplier acceptance can be constrained by fee and integration concerns, and capabilities vary by provider and program. Mastercard-commissioned research also reported that 89% of suppliers said balancing their own needs with B2B customers is difficult. Validate acceptance and program fit by supplier segment before rollout.
If you want a deeper dive, read What Are ePay/ePayables? How Platforms Replace Paper Checks with Virtual Card Payments.
At scale, paper checks tend to break your AP workflow after approval because key steps happen outside one reliable status trail. Your AP system can show a payment as approved while check creation, printing, mailing, deposit timing, and exception handling remain scattered.
A check batch creates multiple handoffs, and any one of them can introduce partial or delayed status. That is usually where the clean AP record starts to drift from what the supplier actually experiences.
AP approves the bill, generates the check, and sends it to print. Those post-approval handoffs can leave status fragmented before the supplier is actually paid.
Physical delivery is another failure point. An AFP press release dated April 16, 2024, reported that over 80% of respondents still send checks via USPS without tracking, and over 20% reported fraud tied to USPS interference. When a supplier says payment did not arrive, teams often have to reconstruct status manually.
Even after deposit, funds are not always immediately available. Under Regulation CC exception hold conditions, a check subject to an exception hold would generally be available no later than the seventh business day after deposit. That timing can contribute to downstream reconciliation lag.
Checks remain a higher-risk rail. In the same AFP findings, 65% of respondents said checks are the payment method most susceptible to fraud. The FBI also warns that check washing alters checks and that compromised checks can clear before fraud is detected.
A major cost is manual follow-up: supplier calls, remittance verification, and spreadsheet tracking to resolve conflicting status. That pressure shows up most clearly at close. As one finance report states, "The month-end close remains one of the most labor-intensive processes in finance." The same reporting says finance teams compare payments, ERP, billing, and bank data with manual investigation and spreadsheets. That slows close work and can pull time from higher-value cash-flow analysis.
A simple checkpoint: for every check batch you still run, confirm you can pull check number, issue date, mail handoff date, amount, payee, and deposit or return status from one operating view without cross-team backtracking.
Digital rails do not remove every exception, but they give you a more consistent evidence chain. Check-heavy workflows often force reconstruction after the fact.
If you are seeing repeated "did it go out?" inquiries, month-end matching drag, or rising exceptions, treat checks as a fallback rail rather than a default. A practical advantage of virtual payables and other digital rails is clearer control visibility. Your team can verify what happened without as much spreadsheet-based backtracking.
If you need high-control, high-visibility B2B payments, virtual cards are often a practical starting point. Use ACH where supplier card acceptance is weak, and keep paper checks as a narrow fallback.
| Method | Speed to delivery | Acceptance friction | Traceability | Exception handling | Reconciliation burden | Cost notes |
|---|---|---|---|---|---|---|
| Virtual Cards | Credentials are issued digitally; settlement timing is program- and supplier-dependent | Can be medium to high for some suppliers due to upfront card-acceptance cost concerns | Strong when each payment has distinct card credentials | Payment-level controls help isolate issues, but supplier processing failures still need routing | Often lighter when payment data and remittance map cleanly into AP records | Program-specific; no universal cost advantage should be assumed |
| ACH Payments | Batch electronic rail; Same Day ACH can deliver within the same business day when eligibility and cutoff conditions are met | Can be lower where suppliers prefer non-card methods and bank details are already set up | Good bank-entry traceability, but less payment-level granularity than one-time card credentials | Timing and processing exceptions still require review | Moderate; typically cleaner than checks, less payment-specific than virtual-card controls | Commonly positioned as efficient, low-cost batched processing, but exact pricing varies by provider |
| Paper Checks | Typically slower operational flow than digital rails | Can still work with suppliers that take checks | Less end-to-end visibility than digital rails | Return handling exists for unpaid checks, but workflows are labor-heavy | Manual handling burden is often higher than digital rails | All-in cost varies by process and is not universally disclosed |
Each rail serves a different operating constraint. ACH remains a core business rail at scale: businesses accounted for 95% of ACH credits by number and 97% by value in 2021. Checks are declining, but businesses still made 52% of check payments by number and 76% by value in 2021.
The key difference is not just speed. Virtual cards use card credentials, including an expiration date and security code, and commercial programs can tie payments to a specific supplier, amount, and expiration date. ACH, by contrast, sends instructions through a nationwide batch network to a bank account.
That difference matters in practice. If you need one payment to one supplier for one approved amount, virtual cards usually map to that intent more directly. If supplier coverage and lower card friction matter more, ACH is often the better route.
For any rail, your AP record should show payment method, supplier identifier, approval reference, remittance reference, provider or bank reference, send time, and final disposition.
Speed is not a single promise, especially on ACH. Same Day ACH is designed for same-business-day delivery when eligible and within cutoff windows, and Federal Reserve Financial Services notes a $1,000,000 Same Day ACH eligibility ceiling. For non-Same Day ACH credits, Nacha states funds availability is required by 9:00 am local time on Settlement Date, effective September 18, 2026.
Checks do have explicit return paths, including unpaid returns such as insufficient funds or closed account, but exception handling is still operationally heavy. Virtual cards have a different bottleneck: supplier-side processing. Mastercard reports that manual processing and reconciliation challenges are a top acceptance barrier for 42% of U.S. suppliers.
Avoid blanket cost rankings. The evidence supports ACH as a generally low-cost batched rail. It also shows some suppliers discourage card acceptance due to upfront costs while card networks argue broader economic value can outweigh those costs. It does not support one universal fee hierarchy across virtual cards, ACH, and checks.
Operationally, a practical default is to use virtual cards where payment-specific control, visibility, and cleaner matching matter most, route acceptance-constrained suppliers to ACH, and keep checks only when neither digital rail is workable.
Related: Virtual Credit Cards for Platforms: How to Issue Single-Use Cards for Contractor and Vendor Payments.
Use a strict if-then routing rule. Choose Virtual Cards (ePayables) first when supplier card processing and traceability are both viable. Choose ACH Payments when card acceptance is the blocker but bank rails are available. Use Paper Checks only as a temporary exception with a defined exit path.
Use ePayables when the supplier can reliably process single-use virtual card credentials and you need payment-level control and clean remittance matching. Virtual payables are built around digital single-use card credentials, including fields such as expiration date and CVV2. That can support clean one-payment mapping to one supplier and one AP record.
Do not treat a generic "yes, we take cards" as enough. Confirm the supplier can process virtual card details and post remittance without manual back-and-forth. Acceptance-friction research from Mastercard, based on over 1,000 supplier-side respondents, is useful as directional evidence. Validate with a controlled cohort before broad rollout.
If card acceptance is the constraint and bank payments are available, use ACH Payments. Nacha positions ACH as broadly reachable across U.S. bank and credit union accounts, with FedACH and EPN as the two national operators.
When you switch rails, keep the audit chain intact. Your ACH routing should preserve the same evidence quality, including supplier, approval, remittance, trace or reference, send time, and final status, rather than pushing matching into email or spreadsheets.
Use Paper Checks only when the supplier cannot yet process virtual cards or ACH, and treat that as temporary by design. Checks are still common, with 91% reported current use in the cited AFP summary, but check risk remains material, with 63% of respondents reporting check fraud exposure in 2024.
Every check exception should include a clear owner, reason, and re-review trigger in your AP workflow so the fallback does not become a permanent shadow process.
Set this as an internal governance rule: require finance, operations, and engineering sign-off before expanding any fallback path that reduces matching quality or visibility. If a route increases unreconciled items, manual follow-up, or off-system tracking, pause expansion and fix those gaps first.
Related: The Best Way to Pay Filipino Virtual Assistants from the US.
Turn those if-then rules into a build-ready rail matrix with policy gates, retries, and status handling: Read the docs.
Launch in stages. Baseline your current rail mix, define the target AP workflow, and run a controlled pilot before broad rollout. That sequence can surface matching, enrollment, and event-model gaps early, before they become month-end failures.
Your outbound AP feed can be multi-rail, not single-rail, and integrated payables can route the same feed to checks, ACH, wires, or cards. Start by baselining vendor payments by rail, supplier, exception rate, and remittance complexity. Then segment suppliers into card-capable, ACH-capable, and check-only temporary cohorts.
Do not build around outliers first. Define the target-state AP workflow in operational terms before building anything. For each payment, document who approved it, which rail was chosen, what remittance payload will travel with it, which status events you expect, and how failed or expired payments will be handled.
For virtual-card flows, treat the payment object as more than an amount. It includes generated card credentials, card number, expiration date, and security code, tied to a specific B2B payment intent. Then run a pilot cohort large enough to generate real exceptions and small enough for end-to-end finance review.
| Artifact | What it should contain | Why it matters |
|---|---|---|
| Payment method matrix | Supplier segment, default rail, fallback rail, approval owner, remittance rules | Prevents ad hoc routing and check creep |
| Supplier Enrollment checklist | Card-acceptance confirmation, remittance contact, ACH bank-detail validation path, first-payment confirmation steps | Keeps enrollment as a core implementation control |
| Electronic Payment File schema | Required fields, rail mapping, validation rules, retry behavior, provider references | Prevents malformed files and downstream posting breaks |
| Exception-routing SOP | Owner and evidence requirements for failed, expired, duplicate, or rejected payments | Keeps exceptions inside AP operations |
For ACH Payments, enforce structural file checks before launch, including File Header Record 101 and Batch Header Records beginning with 5. For first-use ACH bank details, define an account-validation approach, for example prenotes, ACH micro-entry verification, or a commercial validation service, and apply your chosen controls consistently.
Assume retries, duplicate webhooks, and out-of-order events are normal conditions. Require idempotent payment-create and payment-update behavior with unique idempotency keys so retries do not create duplicate operations.
Webhook consumers should log processed event IDs, remain re-entrant, and fetch current payment state when event payloads are partial, stale, or out of order. A practical gate is this: if payment-state changes in the payments layer, the finance dashboard must reflect the same disposition, reference, and timestamp without manual patching.
Do not go live until you pass matching tests for successful, failed, expired, and duplicated payment attempts across Virtual Cards and ACH. For ACH, include an end-to-end bank validation run, such as a production connectivity penny test, and confirm final status appears in the finance view, not only in engineering logs.
Document support boundaries and ownership. Capability is not universal across countries, bank setups, or provider programs, and coverage can vary within a single provider's product set. For each capability, record where it is supported, the last verification date, and who is responsible for periodic re-validation before routing live volume. See Virtual Cards for Contractors and the Real Cost of Getting Issuance Wrong.
Before go-live, make sure each payment can be traced from initiation to final disposition in both your records and your finance view. For each B2B Payment, you should be able to show who initiated and approved it, which rail was used, the provider reference, and the final disposition used in your AP Workflow.
Treat each payment as a sequence of control events, not just one send action. Keep evidence for creation, approval, rail selection, provider submission, and final status so finance does not depend on manual reconstruction.
| Event | Evidence to keep | Why it matters |
|---|---|---|
| Payment created | Internal payment ID, supplier ID, amount, invoice references, initiating user or service | Proves payment origin and scope |
| Payment approved | Approver identity, approval timestamp, policy result, exception note (if any) | Proves the control gate was applied |
| Payment executed | Rail used, provider reference, provider connection/account, affected system/component | Connects internal records to external execution |
| Payment finalized | Final status, status timestamp, settlement/return reference, finance-facing record update | Aligns operations with close and exception handling |
For audit records, include the affected data, system, or component identity, not only a generic event name, consistent with PCI DSS 10.3.6 clarification.
Define logging as a lifecycle process, not just event capture: generation, transmission, storage, access, and disposal. Before go-live, assign ownership for each step, where logs are retained, who can access them, and how they are retired.
A practical minimum is to log the initiator, approver if different, rail, provider reference, internal payment ID, status before and after, timestamp, and final finance-visible disposition. Retries and out-of-order provider events should still produce one coherent payment history.
For virtual-card flows, make masked display the default. PCI DSS 3.4.1 requires PAN masking when displayed, including screens, logs, reports, and receipts, except for specific approved business need.
CVC handling is stricter. PCI DSS 3.3.1.2 prohibits storing CVC after authorization, even if encrypted. Do not store CVC after authorization in debug logs, support tickets, or downstream data syncs, and keep PAN masked in those surfaces.
Apply the same evidence standard to ACH exceptions. Define when AP initiates a Payment Trace Request through the ODFI to the RDFI to confirm whether a payment was not received, returned, or posted.
If your ACH matching depends on Company Entry Description, include that dependency in pre-launch checks in light of Nacha amendments effective March 20, 2026. Across all rails, require a documented exception evidence pack before an item is marked cleared.
Need the full breakdown? Read How to Build a Spend Control Policy for Virtual Cards on Your Platform.
Supplier acceptance usually improves when you enroll by segment, not by mandate. Prioritize suppliers more likely to accept digital rails, then expand. Avoid forcing universal migration up front, because payer rail choice is constrained by what suppliers are willing or able to accept.
Use segmentation across three factors together: payment preference, remittance needs, and readiness for Virtual Cards versus ACH Payments. That gives AP a routing plan that fits supplier operations instead of forcing a one-size-fits-all rollout.
| Supplier segment | What to verify first | Best first rail | Why |
|---|---|---|---|
| Card-ready, high remittance complexity | Supplier can process card payments and has a contact who can receive remittance details | Virtual Cards | Invoice-level remittance detail supports supplier reconciliation |
| Card-resistant, bank-rail ready | Supplier declines card but can receive ACH and provide bank details through your approved process | ACH Payments | Keeps payments digital when card acceptance is low |
| Operationally constrained or unclear | No confirmed card process, no completed ACH setup, or internal approval still pending | Temporary check fallback | Keeps payments moving while enrollment is completed; check remains a secondary rail |
Supplier Enrollment works best when each step has an owner and a completion check. Use a sequence like this:
Lead with the payment change, supplier benefit, and required action. Supplier education is a key acceptance lever, so explain what they will receive, how remittance is delivered, and where to get help.
Capture operational details, not just yes or no: payment contact, remittance email, preferred rail, virtual-card processing readiness, and secure-email status. Check provider scope limits during this step, since some programs require enrolled suppliers in the United States.
Route payment credentials to the right recipient and channel. In virtual-card flows, details may be delivered by email, and card data may be masked when secure email is not enabled.
Enrollment is not complete at send time. Confirm the supplier received remittance, can identify the invoices paid, and successfully processed or posted the first payment.
Clear remittance detail supports supplier reconciliation and can reduce enrollment friction. For virtual-card payments, the remittance should identify the specific invoices being paid, not only the amount and payer name.
Set fallback rules before failures happen. If card acceptance fails, define escalation ownership, reroute timing, and whether the next attempt is ACH or temporary check. Multi-rail AP routing is expected because supplier constraints differ.
Do not treat one rejection as permanent. A program survey reported that 64% of organizations that revisited acceptance with initially resistant suppliers saw greater acceptance. Re-engage after fixing the first-failure cause, such as unclear education, remittance confusion, or wrong recipient routing.
A lot of cleanup work comes from execution drift, not just the initial enrollment decision. Prevent it by treating these four breaks as control points in your AP Workflow before they turn into support tickets.
| Failure mode | Preventive control | What to enforce |
|---|---|---|
| Payment-file schema or field errors | Schema validation before send | Validate payment files before submission so malformed fields are blocked early, especially for XML-based initiation files. |
| Mismatched supplier identifiers | Pre-send identity and destination checks | Match supplier record, approved payment destination, remittance contact, and recent account-detail changes before release. For WEB debits, account validation is a required control before first use and after account changes. |
| Duplicate sends after retries | Idempotency keys | Assign one idempotency key per payment intent so retry attempts return the same result instead of creating a second payment. |
| Unresolved payment exceptions | Explicit rollback handling | Define reversal rules in workflow logic, with ownership and evidence capture. For ACH, reversals are limited to specific error cases, including duplicates and wrong-account sends, and reversing data must stay aligned with the original entry except required processing differences. |
Escalate to leadership when fallback to Paper Checks rises, customer disputes recur, or administrative return rates keep deteriorating. Those trends point to a control weakness, and the risk is material. Checks remain fraud-exposed, with 63% of respondents reporting attempted or actual check fraud in 2024. Sustained administrative return-rate deterioration can also trigger network inquiry once the 3.0 percent level is exceeded.
For a step-by-step walkthrough, see What is a Virtual IBAN and How Do Platforms Use It to Collect Payments Globally?.
Your first 90 days should tell you whether the new rail mix is reducing work or just moving it around. Keep the metric set short, review it monthly, and treat reconciliation as a required control. Track four checkpoints:
Track vendor payments by rail (for example, Virtual Cards, ACH Payments, and Paper Checks) by both count and dollar value. This makes migration visible and helps you separate real mix change from cosmetic volume shifts.
Monitor exception rate, time-to-resolution trend, and unreconciled-item count in each monthly reconciliation cycle. For ACH debits, include unauthorized and administrative return-rate monitoring as exception signals. At least monthly, compare records and ensure differences are investigated, resolved, and documented.
Measure Supplier Acceptance by segment and repeat payment success after initial Supplier Enrollment. Treat enrollment as the start, not the finish: adoption quality shows up when payments process cleanly without repeated manual intervention.
Run one monthly finance-ops-engineering review using the same evidence pack: rail mix, exception log, unreconciled-item aging, and enrollment cohort outcomes. For each segment, make an explicit call to expand, pause, or revert rail usage.
This pairs well with our guide on How Platforms Use Virtual Accounts to Reconcile Incoming Payments Per Client.
The fastest low-risk approach is selective replacement, not a blanket rail migration. Use ePayables where payment-level control and traceability solve a real AP problem, use ACH where supplier fit is better, and keep paper checks as a tightly governed fallback. We would rather see your team scale one clean routing rule than force every supplier onto the same rail.
Virtual Payables are strongest when each payment is tied to a unique virtual card account with supplier-specific amount and expiration controls. They also support cleaner posting when remittance detail and a unique payment identifier are carried in the transaction. If a supplier will not accept cards, ACH remains a core rail, including Same Day ACH for eligible payments up to $1 million.
What keeps this strategy low risk is execution discipline. Generic "go digital" plans can stall when method-selection rules are unclear, supplier enrollment starts too broad, or finance matching is treated as cleanup instead of a launch gate. We recommend treating finance matching as a launch requirement, not a post-launch cleanup exercise.
Use simple routing rules:
Run supplier enrollment in sequence, not all at once. Start with suppliers already able to process card payments, especially where remittance detail matters and check follow-up has been painful. Prove first-payment success and correct remittance application, then expand.
Before scaling, make matching a hard checkpoint. Confirm each payment record includes supplier ID, provider reference, remittance payload, timestamps, rail used, and final AP disposition. If your provider sends ERP finance files, test matching across success, failure, expiration, and duplicate-attempt scenarios.
Stop expansion if these signals appear:
Next step: run a limited pilot with a controlled supplier cohort, apply card and ACH rules in production, and measure rail performance, exception load, and repeat-payment success after first enrollment. The goal is not "zero checks by a fixed date." It is reducing fraud exposure, manual follow-up, and close-process drag without creating a new supplier-acceptance bottleneck. We would rather see your team hold the rollout than widen it without clear evidence on exceptions and supplier fit. Before scaling beyond a pilot, confirm coverage, compliance gates, and operational ownership for your payout mix: Talk to Gruv.
An e-payable virtual card is a B2B payment method that replaces paper-check handling with a digital, supplier-specific virtual card. It uses temporary card credentials, such as a card number, expiration date, and CVC, tied to a payment intent. Its main advantage is payment-level control and cleaner matching back to AP records.
A typical flow is: AP approves the bill, sends the payment file, the provider issues virtual card credentials, and the supplier processes the payment instead of waiting for a check. After processing, status and reconciliation data should flow back into AP or ERP so the payment matches the invoice and supplier record. Use idempotency keys and asynchronous webhooks to avoid duplicate attempts during retries or timeouts.
Choose virtual cards when the supplier can accept card payments and you need tighter payment-level control, clearer status, or cleaner reconciliation. Choose ACH when card acceptance is the blocker but bank-account payments are available. In practice, virtual cards fit one payment to one supplier more directly, while ACH is often better for acceptance-constrained suppliers.
Keep paper checks only when the supplier cannot practically accept virtual cards or ACH, or when a temporary enrollment gap would block a critical payment. Treat checks as an explicit, governed exception rather than a default rail. Checks also create more manual follow-up, weaker status visibility, and higher fraud exposure.
Start by baselining your payment mix, segmenting suppliers by card and ACH readiness, and defining the payment and remittance data needed for reconciliation. Then add idempotency keys so retries do not create duplicate payments. Before go-live, test webhook and internal status handling for success, failure, expiration, and retry scenarios.
Improve supplier acceptance by rolling out in segments instead of forcing a universal migration on day one. Start with suppliers already able to process card payments, send clear remittance details, and confirm first-payment success before scaling. If suppliers cannot process cards, route to ACH quickly so payment speed does not depend on slow enrollment.
Keep a per-payment evidence pack that links the initiator, approver, rail used, supplier record, remittance data, provider reference IDs, timestamps, and final AP disposition. Also document where each method is supported, when that capability was last verified, and who owns re-validation, because coverage can vary by market and program. For card data, mask PAN in displays and logs and do not retain CVC after authorization.
Ethan covers payment processing, merchant accounts, and dispute-proof workflows that protect revenue without creating compliance risk.
Educational content only. Not legal, tax, or financial advice.
The hard part is not calculating a commission. It is proving you can pay the right person, in the right state, over the right rail, and explain every exception at month-end. If you cannot do that cleanly, your launch is not ready, even if the demo makes it look simple.
Step 1: **Treat cross-border e-invoicing as a data operations problem, not a PDF problem.**
Cross-border platform payments still need control-focused training because the operating environment is messy. The Financial Stability Board continues to point to the same core cross-border problems: cost, speed, access, and transparency. Enhancing cross-border payments became a G20 priority in 2020. G20 leaders endorsed targets in 2021 across wholesale, retail, and remittances, but BIS has said the end-2027 timeline is unlikely to be met. Build your team's training for that reality, not for a near-term steady state.