Start with controls before expansion: a legal compliance platform freelancer payments launch should go live only where onboarding can complete KYC, KYB, AML, and required tax-form capture before payouts are turned on. Use a country decision scorecard, tie each release to documented work and approval evidence, and launch one corridor first. Add markets only after operational exceptions remain understandable and records stay reviewable.
Start narrower than you want. A legal compliance platform for freelancer payments should launch with defensible operations before it expands payout coverage or speeds up onboarding. If you cannot show who approved a payment, what obligation triggered it, and which documented basis allowed funds to move, you do not have a real launch sequence yet.
Start with a risk-based approach. FATF treats that as the foundation of AML/CFT because it focuses resources where risk is highest first. For freelancer payments, that means prioritizing customer identity assurance and control quality before adding more rails, more countries, or wallet features.
FATF positions its Recommendations as an international standard that jurisdictions implement through measures adapted to local circumstances, so one payout flow may not work everywhere unchanged. Use a practical test: can your controls operate day to day in that jurisdiction without constant exceptions?
Put customer verification and payment approval in the first release. Onboarding cannot stop at profile data and bank details. Payout activation should depend on completed customer due diligence using reliable, independent information and records that support review.
Use this first internal checkpoint:
If any of those checks depend on off-product workarounds, the launch design is not ready.
Treat reporting readiness as part of the product, not as back-office cleanup. In regulated payment settings, conduct requirements and regular reporting obligations are built into how the service runs.
The UK example is useful for that reason. Payment services include execution of transactions such as transfers. Conduct requirements apply across PSPs, including EMIs. The FCA also expects regular reporting from payment institutions and e-money issuers.
Even if you are not launching in the UK, the operating lesson is the same: if your records cannot support review and reporting, the payment feature is incomplete.
Define launch-ready before you choose markets. The standard is not just that funds can move. It is that funds move with controls that hold up under review. For any transaction, your team should be able to answer quickly:
If you expand corridor coverage before those answers are consistently captured, you create avoidable exceptions and weak evidence trails.
Use this guide in that order: market-entry rules, control checkpoints, recovery actions, and a first-wave checklist. If pressure is pushing you to ship money movement first, pause and narrow scope until controls, records, and reporting readiness can keep up.
For a step-by-step walkthrough, see How Freelancers Choose a Compliance-First Fintech Platform.
A freelancer-payments compliance platform is a governed operating model, not just a payout button. If your product only initiates an ACH transfer or a wire transfer, you have money movement, not a defensible platform.
Define it as one controlled chain from start to finish. The unit you should design and review is the full path: onboarding, approval, payout instruction, and retained records. For each payout, your records should let you reconstruct who was paid, who approved release, what authorized payment, and what happened after instruction.
Test that with one completed payout. If reconstruction depends on email threads, spreadsheets, or personal memory, your audit trail is already weak.
Gate payouts with identity and AML controls before activation. KYC and KYB checks typically belong in onboarding, and AML controls should be active before funds move. In practice, payout activation should wait for completed verification.
Do not rely on a verify-later process after invoices are already payable. That pattern creates manual exceptions and inconsistent records.
Tie each payout to a documented basis and a clear exception path. In freelancer workflows, that often means a governing agreement plus approved-work evidence tied to the release decision. The key is not the label. It is being able to prove why this payment was authorized now, for this party, under these terms.
Carry that link through approval and exception handling. Milestone-style approvals and explicit pending-payment states such as release, cancel, or dispute make decisions auditable instead of implied. For a policy template, see How to Write a Payments and Compliance Policy for Your Gig Platform.
Choose markets you can operate compliantly, not just markets you can sell into. For a freelancer-payments launch, country selection is a controls decision first. If you cannot collect required identity and tax artifacts before payout activation, that market is not ready.
Weight the checks that can break launches: regulatory friction, payout rail availability, onboarding burden, and tax-document complexity. You do not need one universal formula, but you do need explicit tradeoffs before product, legal, and operations drift apart.
| Scorecard area | What to verify | No-go signal |
|---|---|---|
| Regulatory friction | Whether the market creates elevated AML/CFT review needs or other control overhead | You already know the market will require exceptions you cannot staff |
| Payout rail availability | A usable rail exists and can return defensible payment records | Available rails are fast, but records and exception handling are weak |
| Onboarding burden | Your flow can collect required identifying information before activation | Required fields or documents are deferred until after invoices or payouts |
| Tax-document complexity | You can reliably collect and validate forms or numbers relevant to that market | Relevant W-8, W-9, or VAT checks are inconsistent, optional, or manual-only |
Handle tax complexity as a workflow, not a label. In U.S.-relevant flows, Form W-9 is used to provide a correct TIN for IRS information reporting. Form W-8BEN is used by a foreign individual to establish foreign status. In EU VAT scenarios, VIES is a search engine tied to national VAT databases. If VIES returns invalid, the VAT number is not registered in the relevant national database.
Use a practical verification check before you commit the market. Test representative onboarding flows and confirm the required identifying information is collected before account opening or payout enablement. FFIEC guidance is useful discipline here because it expects required customer-identification information before opening the account, and written policies are not enough without working implementation.
Add a FATF AML/CFT-risk overlay, then decide whether the market is launchable now or only with tighter controls. FATF's call-for-action list covers high-risk jurisdictions and urges enhanced due diligence. Its grey list covers jurisdictions under increased monitoring that committed to remediate deficiencies.
Operationally:
FATF public list documents are issued three times a year, so refresh this part of the scorecard on that cycle.
Score worker-model risk by market, because payout compliance does not solve classification risk. If contractor-versus-employee status is unclear, delay scale and narrow the use case.
In the U.S., IRS analysis relies on three evidence categories: behavioral control, financial control, and relationship of the parties. In the UK, HMRC's CEST tool gives HMRC's view of employment status for tax, and HMRC states that wrong status can lead to unpaid tax and penalties.
If your product patterns push toward employee-like control, do not scale based only on KYB or KYC completion. Start with narrower B2B use cases backed by clear contracts and statement-based deliverables, then expand only if classification review stays clean.
Set a hard launch gate. If onboarding cannot reliably collect the required identity and tax artifacts, do not launch payouts in that market. Collect it later usually becomes permanent operating debt.
Before activation, confirm required identity fields are captured and market-specific tax artifacts are collected or clearly marked not applicable. For U.S.-reportable nonemployee compensation, payments of $600 or more trigger Form 1099-NEC reporting obligations. For EU business flows, VAT validation should pass or follow a documented exception path.
You might also find this useful: Handling the FATF Blacklist and Greylist as a Freelancer. If VAT readiness is part of your go/no-go score, run a quick pre-launch check with the VAT number validator.
Map the money flow and the evidence flow before vendor selection, or you will build gaps you cannot explain later. Define each handoff first, set an audit-trail checkpoint for that handoff, and then choose tools that preserve those records.
Make the lifecycle explicit in the order funds and evidence move: client payment initiation, internal ledger posting, FX handling when currencies differ, payout instruction, status updates or inquiries, and confirmation. Treat those as separate control points, not one event.
For each completed payout, you should be able to show one trace with initiation, ledger recognition, FX handling if any, payout send event, and confirmation. If that chain is not reconstructable from IDs and timestamps, the operating risk is hidden inside the stack.
Assign rails by use case, not by habit. A Virtual Bank Account, or VBA, is often useful for bank-transfer identification and reconciliation across receivable and payable flows. Model it as a sub-ledger tied to a physical account, not as a separate fund-holding account.
For outbound lanes, ACH transfer and wire transfer serve different needs. ACH is a U.S. batch network and is often a fit where batch timing works. Wire supports same-day, mission-critical movement and explicit confirmation handling. Choose the rail based on corridor needs, timing tolerance, and failure cost, not on one default applied everywhere.
Tie each payout approval to legal and delivery evidence so the payment is explainable. In contract-driven flows, link the governing B2B contract, the relevant Statement of Work, and the specific service or deliverable being paid.
That keeps review focused on authorization and performance, not just transaction metadata. If reviewers cannot open contract references and match SoW scope or milestones to the approved amount where applicable, the flow is not ready for full automation.
Define status states and escalation ownership before launch. You do not need a universal taxonomy, but you do need an enforced set such as pending, held, returned, and failed, plus a clearly assigned owner for each path.
Set one hard rule from day one: no approved profile and no payout rail activation until identity, business, AML, and tax checks are complete.
Gate money movement on verified onboarding, not just submitted fields. Require identity and business verification before the account can transact, and split individual and entity onboarding paths early.
For entities, collect legal business details and, where your provider or program requires it, beneficial ownership information at account opening. Keep the account non-transactable until verification is approved. Providers may enforce this by requiring specific information before enabling charges and payouts, and by keeping payouts disabled when verification fails.
Apply AML controls before funds move. A practical design reference is customer due diligence that combines identity checks, beneficial ownership checks, relationship-purpose understanding, and ongoing suspicious-activity monitoring.
Operationally, use pre-payout hold states tied to a review queue with evidence fields. The hold should happen upstream of the first payout so review pending does not turn into post-send cleanup.
Collect tax profiles during setup, before the first invoice or withdrawal. For U.S. payees, collect W-9 and validate that the TIN matches the name on line 1 to reduce backup-withholding risk.
For foreign beneficial owners in relevant U.S. withholding or reporting contexts, collect the applicable W-8. Often that is Form W-8BEN for individuals. Track validity and refresh timing. If required tax setup is missing and payments proceed, backup withholding can apply at 24 percent in applicable U.S. payer withholding situations.
Make payout activation a separate checkpoint that follows verified completion. Do not enable ACH, wire, or other payout methods until required verification and tax records are valid for that payee type.
Use a minimum activation checklist:
If your provider uses ownership thresholds such as 25% or more, store that as provider-specific program logic, not as a universal rule. The control objective does not change. If the profile is not approved, the payout rail stays off.
Once onboarding is complete, the next control is proving why each payout was owed. Build the record so a reviewer can reconstruct contract basis, scope, acceptance, tax status, and settlement movement without cross-team forensics.
Set platform-default terms for every B2B contract: an Intellectual property clause, a Confidentiality clause, and a Dispute resolution clause. Those clauses clarify ownership, confidentiality duties, and where and how disputes are handled.
Keep the language precise. These clauses are not universally mandatory across all jurisdictions, but they are strong defaults. For confidentiality, an NDA is an agreement that specified information remains confidential. For IP, define what rights transfer, when they transfer, and what the freelancer retains.
Treat dispute language as a high-scrutiny term, especially for cross-border work. The ICC publishes standard arbitration-clause language, and its 2021 Arbitration Rules entered into force on 1 January 2021. If you do not use ICC language, require legal approval for any deviation from your default clause before launch.
Require a matching Statement of Work for every payable engagement, and link the payout to that SoW ID. A defensible SoW should include concrete fields such as work description, location, period of performance, deliverable schedule, and performance standards.
Acceptance evidence needs to map back to those terms. Before payout approval, the reviewer should be able to identify the exact milestone, the acceptance record, and the acceptance date. If any of that is missing, hold the payout.
Write the required evidence into the SoW itself instead of improvising later. That can be in-app signoff, a recorded milestone approval, or an uploaded acceptance document, but it should be required at milestone level.
Avoid retroactive matching. Paying first and backfilling contract or approval records later creates a weak file and makes disputes and audits harder to resolve.
Document contractor-versus-employee classification decisions before the first payout, especially in higher-risk markets. In U.S. federal tax context, IRS analysis looks at evidence of control and independence, so your file should show more than a contractor checkbox.
At minimum, keep the signed contract, the SoW, and the written classification rationale. If facts are unclear or disputed in the U.S., Form SS-8 is the formal path to request a worker-status determination.
Manage the tradeoff directly. Tight milestone controls can improve payout defensibility, but heavy day-to-day direction can raise classification questions under control-and-independence tests. If supervision is close and continuous, reassess whether the role still fits a contractor model.
Use one payout evidence pack as a single audit trail for legal, tax, approval, and settlement records. The goal is a chronological file that lets you reconstruct and examine the payout sequence months later.
| Evidence item | What it supports | Verification checkpoint |
|---|---|---|
| Signed contract | Legal basis, IP/confidentiality/dispute terms | Executed version stored with full signature record |
| SoW | Scope, milestones, period of performance, standards | SoW ID linked to payout and milestone reference |
| Approval log / acceptance record | Proof that delivery was accepted | Date, approver, and accepted milestone are visible |
| Tax profile | Reporting and withholding posture | Valid W-9 or applicable W-8BEN on file |
| Provider settlement ID / Trace ID | Payment traceability | Settlement identifier stored on payout record |
Preserve signature authentication, audit logs, and secure document storage for e-sign flows. Store the provider settlement identifier on each payout record. A Trace ID helps track delayed or missing payouts, including escalation when funds have not arrived after 10 business days. Keep the distinction clear. Traceability shows where money moved, not whether payment was contractually owed.
Include tax records in the same pack. A W-9 provides TIN data to payers that may need to file information returns, and W-8BEN is submitted when requested by the payer or withholding agent. If required TIN data is missing, backup withholding may need to begin immediately, so surface that before payout, not after. This pairs well with our guide on Cross-Border Freelancer Risk Mitigation Through Structure and Compliance.
Choose payout rails for legal defensibility first, then optimize fees. If a rail is fast but cannot produce a clear compliance record, keep it out of the initial launch.
Treat ACH transfer, wire transfer, and VBA-linked flows as different compliance choices, not as equivalents.
| Rail or setup | Defensibility signal | Main tradeoff | Launch judgment |
|---|---|---|---|
| ACH transfer | ACH is a U.S. batch network, and Nacha Operating Rules are the foundation for ACH payments | Batch processing does not carry the same immediate finality signal as real-time wire settlement | Use where ACH fits your corridor and your provider exposes complete payout records |
| Wire transfer | Fedwire-style wires are immediate, final, and irrevocable once processed | Cost and operational tradeoffs vary by provider and corridor | Use when settlement finality matters more than fee savings |
| VBA-linked flow | Compliance strength comes from the underlying outbound rail and its bank or provider artifacts | Clean product UX can hide weak underlying evidence | Approve only after validating the actual payout rail and document outputs |
Use a simple rule. Evaluate the underlying money movement and artifacts, not the front-end payout label.
For bank-transfer channels, controls must be rail-aware because funds-transfer systems can be used to disguise source of funds. Validate what data is collected, retained, and retrievable for each rail.
In U.S. bank-transfer context, FFIEC guidance points to collection and retention requirements for certain funds transfers of $3,000 or more. The same guidance states ACH is excluded from the specific funds-transfer definition in 31 CFR 1020.410(a). That is a scoping distinction, not a reason to treat ACH as documentation-light.
Before enabling any rail, verify that a sample payout shows execution date, settlement or trace identifier, status, and linkage to the approved payout record.
For India-facing corridors, validate which inward-remittance artifact your banking chain requires (for example, FIRC where applicable), and do not assume labels are interchangeable across banks.
RBI guidance states the bank that converts foreign currency into INR is the bank required to issue the FIRC. RBI's updated FEMA directions dated January 16, 2026, effective October 01, 2026, place adherence responsibility on authorised dealers.
Operationally, confirm which bank performs FX conversion, which inward-remittance artifact is issued, and how that artifact is attached to the payout file.
Pre-approve a fallback rail per corridor. Keep one fallback rail per corridor so failures do not force off-policy manual payouts.
Do not scale payout volume until tax-form collection, reporting logic, and filing evidence map back to the same payee record.
Make tax-form collection a payout gate in onboarding, not a support follow-up later. For U.S. payees in an independent-contractor flow, start with Form W-9 and retain it for four years. For foreign beneficial owners, collect Form W-8BEN before payout.
Use one operating rule: if the required form is not on file and retrievable, do not enable payout. If payouts already moved with missing W-9 data, review whether 24% backup withholding applies when required TIN conditions are not met.
Your filing logic should separate worker status, payment type, and payment rail before year-end. Use Form 1099-NEC for qualifying nonemployee compensation, including amounts of $600 or more, and do not use it for employee wages, which belong on Form W-2.
Use Form 1099-MISC for categories such as rents, royalties, prizes, and other fixed determinable income. That includes IRS examples of at least $10 in royalties and at least $600 in rents and other listed categories.
Before filing, review edge cases at the record level. For payees tagged to 1099-NEC, confirm a W-9 is present, nonemployee compensation is at or above $600, and the payment was not processed as a card or certain third-party network payment that is reported on Form 1099-K by the payment settlement entity.
Keep freelancer-facing tax help factual and non-personalized. For FEIE, state that it applies only to qualifying individuals with foreign earned income who meet requirements and file a return. For tax year 2026, the maximum exclusion is $132,900, and it reduces regular income tax but not self-employment tax. For FBAR, state that a U.S. person must file FinCEN Form 114 if aggregate foreign account value exceeded $10,000 during the year, with a due date of April 15 and an automatic extension to October 15.
Do not tell freelancers they personally qualify for FEIE or that a specific account is definitely reportable or not reportable for FBAR.
Tax decisions should be traceable from one evidence set. Your export should tie each filing outcome to the payee record, the stored W-8BEN or W-9, and the payout history that triggered that treatment.
If tax-document completion drops below your internal target, consider pausing new-market rollout while you fix onboarding leakage first.
Choose the operating model per transaction flow, not once for the whole company. A Merchant of Record, or MoR, setup can shift who is responsible in some flows, but it does not remove platform responsibility in every configuration.
Start with one test: who takes the customer payment, appears on the receipt or statement, and is responsible for the purchased service. In Stripe Connect, that answer changes by charge pattern: with direct charges, the connected account is the merchant of record; with indirect charges that do not use on_behalf_of, the platform is.
That choice also changes liability and reporting. Where the platform controls pricing, Stripe assigns the platform responsibility for relevant 1099 filing. And if a connected account balance goes negative, Stripe says the platform is still in the end responsible for losses.
If speed is the priority, use MoR-style coverage only where the provider explicitly supports it. Stripe states Managed Payments makes Stripe the merchant of record for eligible digital-product transactions and manages indirect tax compliance in more than 80 countries.
If you need tighter control over contract terms, acceptance logic, or payouts, keep more in-house and plan for more compliance ownership.
Do not stop at country availability. Confirm verification scope by country, business type, requested capabilities, and the specific program you plan to launch. Stripe states verification requirements vary by country, capabilities, and business type. Adyen requires verification before you can process payments or pay out funds, and its required data formats vary by country or region.
A practical recovery path after a messy launch is to stop expanding, stabilize controls, and rebuild evidence quality before volume increases.
If identity or AML checks are inconsistent, consider pausing new corridor activation until controls are stable. AML programs are expected to include internal controls and ongoing monitoring, so one recovery approach is to route new applicants to manual review and re-check accounts approved during the unstable period.
Verify the recovery with a sample. Confirm minimum identity data was collected before account enablement, and confirm monitoring can still trigger holds or reviews after onboarding when suspicious activity appears. After onboarding rules are fixed, also review profiles that were already approved during the unstable window.
Weak documentation links make disputes and audits harder to resolve. For stronger auditability, each payout record should connect the governing B2B contract where used, the matching Statement of Work, the approval event, and the contractor tax profile on file, such as W-9 where applicable.
Enforce immutable references on new approvals, then backfill older payouts where the SoW is missing scope, period of performance, or deliverable schedule.
Test the fix by asking a reviewer to reconstruct one paid transaction from the audit trail alone. If they still need inbox or chat history, the linkage is not strong enough. Record retention can become part of the risk as well. Many required records may need to be retained for five years, while a W-9 is kept for four years in payer files.
Do not scale on a rail that makes failed payments hard to investigate. For transfers of $3,000 or more, record quality is critical because key payment details such as originator, amount, date, instructions, and beneficiary bank support defensible review.
If exception data is weak, shift early volume to rails and workflows with better return tracking and documentation-attachment support. In ACH exception handling, supporting documents can be attached, and an ODFI Request for Return response window can run to 10 banking days. The tradeoff is often cost or speed, but that is usually easier to manage than manual payout recovery with weak records.
Use phased rollout as a control strategy: clear the market, lock onboarding gates, require payout evidence, then prove one corridor under live volume before expanding.
Start with a go or no-go on the country, not the rail. Score at least FATF posture, worker-classification risk, and whether you can reliably collect the identity and tax artifacts your model depends on.
Use FATF statements dated 13 February 2026 as the baseline. FATF calls for enhanced due diligence for high-risk jurisdictions, while increased-monitoring jurisdictions are not automatically subject to enhanced due diligence, but should still be included in risk analysis. Treating grey-list status as an automatic block can be over-restrictive. Ignoring it misses a clear risk input.
Keep classification in the same scorecard. The IRS common-law view examines behavioral control, financial control, and the relationship of the parties, and written contracts are part of that relationship evidence. If you cannot support contractor status with documents and operating facts, delay scale in that market.
Do not enable withdrawals before identity and tax readiness. If your model uses KYC, KYB, and AML controls, make them hard gates before the first payout.
For legal entities, include beneficial-owner checks where required in the gate. Test this directly: withdrawals should stay disabled until required profile fields, identity checks, business details, and beneficial-owner data are complete.
Where U.S. payer or withholding context applies, collect the right form at setup. Form W-9 provides a correct TIN to a payer filing an information return. Form W-8BEN is provided by a foreign beneficial owner to a payer or withholding agent. Do not treat W-8 or W-9 as universal global forms.
Make every payout traceable to work and approval. As an internal control, require links to a contract or scope record (such as a SoW or invoice) and a dated approval record.
Set a structural rule: a payout is not submit-ready without a contract or scope reference, approver identity, and a transaction or settlement ID once executed. If those records exist only in email or chat, your audit trail can break down when exceptions or disputes appear.
Launch one corridor first, then decide with production data. Track hold rate, failed payout rate, return rate where applicable, and evidence-pack completeness.
If the rail is ACH, treat the 3.0 percent administrative return-rate level as an ACH-specific watchpoint that can trigger inquiry activity. Do not apply that threshold to wires or other rails. For wires, payment finality raises the importance of pre-release controls. Expand only when records stay complete and failures remain understandable under real traffic.
Copy/paste checklist for first launch wave
When your launch checklist is locked and you need to confirm market and program fit, talk with Gruv.
As a practical baseline, set identity checks before payout enablement, maintain a documented AML program, collect tax forms, and keep payout records tied to a real payee and payment instruction. If you benchmark against regulated-bank expectations, the baseline also includes internal controls, testing, designated responsibility, training, and ongoing risk-based due diligence. For legal-entity customers, beneficial-owner identification at account opening is a core checkpoint.
Use three screens first: FATF posture, onboarding evidence you can reliably collect, and whether your payment rail produces usable records. FATF high-risk call-for-action status supports enhanced due diligence expectations, while increased-monitoring status is different and is not automatically subject to FATF-called enhanced due diligence. If one market supports cleaner identity, beneficial-owner, and tax-document capture, it is often the lower-risk launch choice.
Do not skip identity verification, beneficial-owner checks for legal entities, ongoing suspicious-activity monitoring, tax-form capture, and payment-order traceability. W-9 supports correct TIN collection for payer reporting, and a missing or incorrect TIN can create backup-withholding issues. For foreign beneficial owners, W-8BEN is provided to the payer or withholding agent when requested.
Use a Merchant of Record model when you want another entity to be legally responsible for processing customer payments and related transaction-compliance obligations. It can be practical when speed to market matters more than owning every payment control in-house. Do not assume MoR removes all of your responsibility. Confirm exactly who owns onboarding checks, tax-document handling, record exports, and dispute evidence.
Prioritize trace quality and record completeness over marketing labels. ACH transfer is batch-based, processes 23¼ hours every banking day, settles four times every banking day, and does not settle on weekends or federal holidays, so exception timing matters. In the Fedwire context, a wire transfer is immediate, final, and irrevocable once processed. A Virtual Bank Account can improve sub-ledger attribution, but it does not replace outbound payment-order recordkeeping.
Use a consistent evidence pack, such as governing contract or accepted terms, invoice or Statement of Work with scope and period, approval record, payee tax form such as W-9 or W-8BEN, and provider settlement or transaction IDs. For covered transmittals of funds at $3,000 or more, records should capture originator identity, amount, execution date, payment instructions, and beneficiary-bank identity. Keep retention obligations in view because some recordkeeping duties can run for up to five years.
Avery writes for operators who care about clean books: reconciliation habits, payout workflows, and the systems that prevent month-end chaos when money crosses borders.
Priya specializes in international contract law for independent contractors. She ensures that the legal advice provided is accurate, actionable, and up-to-date with current regulations.
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.