Public HMRC and GOV.UK guidance does not currently confirm that MTD for Income Tax directly applies to UK platform operators solely because they run a platform. The confirmed rules are still useful: the guidance is framed around sole traders and landlords, with digital records, quarterly updates, compatible software, and an annual tax return by 31 January. Build around those confirmed mechanics and route operator-scope questions to legal review.
For platform operators, the first useful move is to separate confirmed HMRC and GOV.UK statements from scope assumptions. Most public guidance on Making Tax Digital for Income Tax is written for sole traders, landlords, and their agents, not for platform operators as a distinct audience.
That framing matters. Public pages present MTD for Income Tax as a way for sole traders and landlords to report income and expenses to HMRC. Before you set controls, use that as a checkpoint. Are you relying on taxpayer guidance, or on guidance that actually speaks to platform operators?
The confirmed pieces are still operationally useful. The guidance covers creating, storing, and correcting digital records, sending quarterly updates, and then submitting a tax return and paying tax due by 31 January the following year. It also states that from 6 April 2026, sole traders and landlords with annual self-employment and property income over £50,000 must use MTD for Income Tax.
At the same time, platform-operator reporting sits in separate GOV.UK guidance for digital platforms, including collecting and checking seller information and reporting seller details to HMRC. That is a real reporting regime, but it is not the same as confirmed evidence that MTD for Income Tax creates direct platform-operator duties in the same way.
This article uses a simple operating rule: classify requirements as confirmed, inferred, or unconfirmed, then assign ownership and escalation. The goal is to build around confirmed mechanics now while routing unresolved scope points to legal review, instead of turning them into automatic engineering requirements. For a separate platform-compliance walkthrough, see EU Digital Services Act for Marketplace Operators.
On GOV.UK, MTD is the broader modernisation programme. The guidance used here is narrower: Making Tax Digital for Income Tax is framed for sole traders and landlords, with eligibility and process language tied to people in Self Assessment with self-employment income, property income, or both. Those taxpayer terms are the working vocabulary for this piece.
For platform teams, treat "HMRC digital reporting mandate" as a constraint to map and monitor, not as proof that every UK platform operator is directly mandated under this Income Tax stream. HMRC also has separate digital platform operator reporting guidance for seller reporting, and operators may need to register with HMRC under that regime. Do not collapse that regime into MTD for Income Tax just because both involve digital reporting. Use a short shared definitions note across compliance, legal, finance, and product. At minimum, define:
Before making build decisions, check recent tickets and requirements docs for consistent use of these terms. If the terminology is mixed, fix the glossary first, then reopen scope.
Related: Making Tax Digital (MTD) Acceleration: How Platforms Can Automate UK VAT Reporting.
The confirmed position is still taxpayer-scoped. Public HMRC and GOV.UK material for MTD for Income Tax addresses sole traders and landlords, and it does not visibly confirm a separate direct obligation on UK platform operators purely because they operate a platform.
That distinction should drive your build decisions. Digital records, quarterly updates, and annual return timing are confirmed mechanics. The open point is whether, and when, those mechanics create direct obligations for your platform under this Income Tax stream.
Public guidance is clear on the audience and mechanics. It shows:
The unresolved question is operator scope. In public sources, there is no direct rule text saying a platform is separately in scope for this regime solely because it is a platform operator. The 2026 explanatory memorandum describes affected taxpayers as unincorporated businesses and landlords, which supports a taxpayer reading.
Treat future expansion the same way: keep it in the legal-review lane. GOV.UK says partnerships are expected later, but the timeline is not yet published.
Use a live register so confirmed mechanics do not get mixed up with unconfirmed scope calls.
| Confirmed from GOV.UK / HMRC campaign site | Open questions requiring legal confirmation |
|---|---|
| MTD for Income Tax is presented for sole traders and landlords reporting income and expenses to HMRC. | Is a UK platform operator, as operator, directly in scope under this Income Tax regime? |
| Eligibility language is tied to Self Assessment, self-employment income, and property income. | For mixed user bases, when do user tax obligations become platform obligations, if at all? |
| In-scope taxpayers must keep digital records and use compatible software. | Must the platform build MTD-specific controls, or can it rely on user-side software and provide support records only? |
| Quarterly updates are required every 3 months for each self-employment and property income source. | If platform transaction data is used, what is the legally relevant record set and required detail? |
| The annual deadline is 31 January after the relevant tax year. | Who owns interpretation where this stream intersects with separate HMRC platform reporting obligations? |
| Public start dates are 6 April 2026, 6 April 2027, and 6 April 2028 by qualifying income band. | Which platform segments should be excluded from scope assumptions until legal confirms otherwise? |
Review this register weekly until scope is settled. For each confirmed row, keep a current source snapshot, capture date, and owner.
If a control depends on an unconfirmed interpretation, label it monitor + legal review, not mandatory build. Reserve mandatory build for controls backed by public HMRC or GOV.UK wording, or by legal advice that cites the underlying rule text.
Use adviser commentary to sharpen questions, not to close them. Adviser material can help frame the issue, but final interpretation should stay anchored to current legislation and GOV.UK guidance.
Related reading: A Guide to Greece's Digital Nomad Visa and Its 50% Tax Break.
Make ownership explicit early, because blurred ownership is how assumptions turn into builds. Appoint one accountable owner for the known vs unknown decision log, then split execution so legal interprets scope, finance runs reporting operations, engineering owns system controls, and compliance tests defensibility.
Use a compact RACI tied to the HMRC nouns your controls depend on: Self Assessment, MTD-compatible software, and HMRC APIs.
| Work item | A | R | C | I | Key artifact or dependency |
|---|---|---|---|---|---|
| Policy interpretation and scope status | Legal | Compliance | Finance, Engineering | Exec sponsor | Confirmed-vs-open register, GOV.UK snapshots, legal memo on sole traders and landlords |
| Filing operations and submission readiness | Finance | Finance operations | Legal, Engineering | Compliance | MTD-compatible software, quarterly update calendar, annual return checkpoint for 31 January |
| System controls and integrations | Engineering | Engineering | Finance, Compliance | Legal | HMRC APIs, interface specs, data validation rules, audit logs |
| Assurance and evidence quality | Compliance | Compliance | Legal, Finance, Engineering | Exec sponsor | Control matrix, exception register, sample record trace, remediation history |
| Mixed-model escalation for user treatment | Legal | Compliance | Finance, Engineering | Product or ops lead | Segment rules for sole traders and landlords, escalation log, decision date, decision owner |
The first row is the control point. If no one owns requirement-status labels, teams will fill the gap with assumptions and unconfirmed points will be treated as mandatory builds.
Legal should own interpretation because public MTD for Income Tax wording is taxpayer-led, with sole traders and landlords in Self Assessment at the center. In mixed models, unresolved treatment questions for those groups should escalate to that legal owner, not be settled informally.
Finance should own the operating calendar and handoffs. Keep quarterly updates and the annual return as separate procedure checkpoints, because quarterly updates are summaries, not tax returns. Where multiple agents are involved, make sure one combined update is sent for each update period.
Engineering should own field-level truth: capture, correction versioning, and API mapping quality. Some MTD API parameters map to Self Assessment box numbers. Run cross-team sample checks so finance, compliance, and engineering interpret the same fields the same way.
Compliance should test traceability end to end: source event to digital record to quarterly summary or annual output, with no undocumented manual edits. A successful submission is not enough if the correction path or dataset version cannot be explained.
If you make one structural change, make it this: require every scope decision to record evidence, owner, and review date under a single accountable decision-log owner. If you need the full breakdown, read HMRC Reporting Rules for Platforms for UK Marketplace Operators.
Use a three-state rule. Build only what current HMRC or GOV.UK text clearly requires, monitor unresolved interpretation or technical gaps, and defer speculative work.
| State | Use it when | What you do now | Trigger to reclassify |
|---|---|---|---|
| Build now | Current GOV.UK or HMRC wording is explicit | Implement controls, evidence, and operating steps | Updated guidance changes the rule or timeline |
| Monitor | Outcome depends on legal interpretation or unverified technical detail | Log owner, source page, review date, and impact | Page update, HMRC clarification, or legal advice resolves it |
| Defer | Work is speculative or tied to a later phase with no current operational impact | Do not build; record why | Threshold, rollout date, or scope change makes it material |
Anchor decisions to the current eligibility and software guidance pages, not to memory or older planning docs. HMRC frames eligibility as conditions-based. That includes being a sole trader or landlord in Self Assessment and meeting the relevant qualifying income threshold. The current threshold phases shown are £50,000 from 6 April 2026, £30,000 from 6 April 2027, and £20,000 from 6 April 2028.
Record the page and last-updated date in your log. That matters because older policy material describes a two-phase rollout for individuals, while the current eligibility page adds the 2028 threshold phase.
If you already capture records for self-employment income and property income, strengthen traceability before adding more tooling. Prove where records originate, how corrections are versioned, and which dataset produced each quarterly submission.
That sequence matters because HMRC describes quarterly updates as summaries, not tax returns. If records already exist, improve control evidence first instead of duplicating capture.
If a requirement depends on missing detail from the MTD for Income Tax end-to-end service guide, mark it as a technical gate and assign an owner and date. Track exactly which component is blocked.
Handle API-list details carefully as well. The HMRC GitHub API list says it is generated and not updated automatically, so do not treat it as a self-refreshing source of truth.
Escalate to specialist advice when legal interpretation would change your data model, integration design, or control structure. HMRC guidance points complex tax affairs toward specialist tax-agent support. Use the same internal threshold when the interpretation would materially change what you build.
Before committing engineering time, map each requirement to the control surfaces you already run. Then document any gaps against your target operating model in the Gruv docs.
Fix lineage before integrations. In this part of MTD for Income Tax, the main risk is usually not sending data to HMRC. It is being unable to prove where each reported figure came from, how it was corrected, and which supporting records still exist.
That follows from the current rules and guidance. Required digital records must support both quarterly updates and the annual return, including amounts and the dates items were received or incurred. HMRC guidance also sets an end-to-end flow through compatible software: create, store, and correct digital records, send quarterly updates, then submit the tax return.
Start from source events and work outward. For a sole trader or landlord case, identify where the tax-relevant record is created, which fields are captured, where it is retained, and how it flows into quarterly and annual outputs. Do not start with the submission schema alone, because quarterly updates are software-generated totals.
| Stage | What to map | Why it matters |
|---|---|---|
| Source event capture | Origin of income or expense record, amount, transaction date, record owner, source document reference | Required records include amounts and dates received or incurred |
| Validation | Checks before a record is treated as reportable | Stops bad records from rolling into quarterly totals |
| Correction path | How errors are amended, versioned, and linked to the original record | Quarterly updates include corrections and generally do not require resending the original update |
| Quarterly output | How records roll up to period start and end dates and category totals | Quarterly update information includes period boundaries and totals by income and expense category |
| Annual output and retention | How the same records support the tax return and where supporting documents are kept | You still need original records or supporting documents used to prepare the return |
Most failures show up here: records exist, but they are not actually reportable. One system may keep an amount without the tax-relevant date, or a date without a link to the supporting document.
Treat correction lineage as a first-class design requirement. Quarterly updates can include corrections to earlier records, and the guidance indicates you usually do not resend the original quarterly update. That only works if changes are preserved instead of overwritten.
A common failure mode is silent edits: the current value looks right, but the prior value, edit date, and reason are gone. Then you cannot explain why quarterly totals moved. Because quarterly updates are summaries and can be sent before accounting or tax adjustments, your records should clearly separate captured activity from later adjustments.
Most rework starts at handoffs between your systems and MTD-compatible software. Missing dates are a frequent cause. If one system holds payout date while another expects the transaction date used for reporting, period totals can be wrong.
Identifier drift is another problem. HMRC does not prescribe a payer or payee identifier schema here, but reconciliation becomes fragile when systems use different entity keys without a stable crosswalk. Category overwrites are the third. If category mapping changes in place without history, you lose the trail for why totals shifted between categories.
Before you go deeper on integration, set one verification gate. Can your team reconstruct a sampled sole trader or landlord quarterly total from the summary back to the underlying digital records, including corrections and supporting documents? This is an internal control choice, but it is the fastest test of whether lineage is actually operational.
Use a concrete sample pack: one quarterly total, underlying records, included corrections, linked support documents for Self Assessment, and retention coverage for at least 5 years after the 31 January submission deadline. If the trail breaks, fix lineage first. HMRC provides APIs through the Developer Hub, but integration on top of weak records usually multiplies rework.
If you want a deeper dive, read A Guide to 'Making Tax Digital' for UK Freelancers.
Pick the filing route that matches your control needs and your ability to support it over time. Choose software-led first when you need a reliable filing path from records that are already traceable. Choose direct API integration only if you can support ongoing engineering ownership and need custom controls that packaged tools do not provide.
HMRC does not provide software for MTD for Income Tax. GOV.UK points users to commercial compatible software, including bridging software. It also says you should confirm that the product meets your specific needs, including supported income-source scenarios and your record and correction process.
Use this as a decision framework. It is not an HMRC ranking.
| Route | Implementation effort | Control granularity | Exception visibility | Change management risk |
|---|---|---|---|---|
| Compatible software | Often lower at go-live because core record, correction, and submission steps are built in | Limited to product capabilities | Usually clear for standard flows | Roadmap and support coverage are vendor-managed |
| Bridging software | Often lower if records already live in spreadsheets or existing files | Narrower, often submission-focused | Depends heavily on upstream data quality | Sensitive to mapping, file changes, and unsupported cases |
| Direct HMRC API integration | Higher, because your team owns build, test, and operations | Highest potential, because you design the controls | Strong if you build explicit error and reconciliation handling | You own endpoint monitoring, version checks, and regressions |
If you need speed and your case fits current software coverage, a software-led rollout is often the faster path. If you need record-level approvals, custom exception queues, or tailored audit outputs, API-led design may justify the extra build and maintenance load.
Use the Making Tax Digital for Income Tax end-to-end service guide to frame technical constraints and integration questions. Keep policy interpretation in a separate legal and compliance decision log.
Treat recency as a control point too. The service-guide API list warns that it is not updated automatically. Before you commit build effort, verify endpoints in the HMRC Developer Hub and current API catalogue, then test feasibility in sandbox.
Before you commit, force the route to prove itself in a small test.
For software-led options, get written confirmation that your use case is supported, especially where income-source coverage may still be evolving.
For API-led routes, prove one sandbox end-to-end flow before you scale the design. Test record creation, correction handling, rolled-up quarterly output, HMRC authorization, and an audit export that compliance can review without engineering support.
Keep the scope boundary explicit throughout. The guidance used here is framed around sole traders, landlords, and agents, including the 6 April 2026 start point for some taxpayers over the £50,000 qualifying-income threshold. Do not treat that framing as proof of platform-operator scope.
This pairs well with our guide on GST Digital Marketplace Platform Comparison for Australia, Canada, and India.
Anchor the operating calendar to the annual Self Assessment cycle first, then layer quarterly checkpoints where your confirmed scope analysis says they apply. That keeps the control routine stable even while some operator-scope questions remain open.
The public anchors used here are limited but useful. The tax year runs from 6 April to 5 April. When trading starts, records must be kept. Those records support profit-or-loss calculations for the tax return. The excerpts also state that registration as a sole trader is done through Self Assessment, and that someone already registered for another reason must register again as a sole trader. Those anchors are enough to run a basic operations routine:
| Control point | Grounded basis vs internal design | Owner |
|---|---|---|
| Record capture and retention | Grounded: keep records from the start of trading; use them for tax-return profit/loss | Finance |
| Submission readiness review | Internal design: decide when data is approved for filing and who signs off | Finance + compliance |
| Submission and response handling | Internal design: run filing route, capture responses, route rejections | Finance + engineering |
| Exception and correction loop | Internal design: any data-changing correction triggers re-approval before resubmission | Finance + engineering |
| Year-end close | Grounded annual anchor: reconcile records to the yearly Self Assessment position | Finance + compliance |
Keep handoffs explicit so approvals are not bypassed. Finance confirms filing readiness. Engineering confirms that the submission path works and preserves response history. For each cycle, keep a signed control log showing what was submitted, by whom, and against which dataset version as internal evidence.
For date controls, the excerpt example says HMRC must be told by 5 October 2025 for the previous tax year (6 April 2024 to 5 April 2025), and late notification can lead to penalties. Treat this as a recurring annual verification item, not a date you hard-code forever. Those same public materials do not, on their own, establish direct MTD for Income Tax obligations or quarterly submission rules for platform operators as operators.
We covered this in detail in Creator Platform Tax Reporting for 1099 and W-8 Expansion Decisions.
Treat exceptions as a routing problem first, not a fire drill. Separate scope ambiguity from execution failures so routine defects do not automatically become legal escalations.
Use a simple category-to-owner map in your exception register, with one named owner per item:
| Exception category | Primary owner | What belongs here |
|---|---|---|
| Policy ambiguity | Legal (or specialist tax advisor) | Questions about whether your fact pattern fits HMRC's published scope |
| Data quality | Finance or operations | Inaccurate or incomplete digital records, recurring correction churn |
| Integration defects | Engineering | Broken mappings, failed software handoffs, submission-path defects |
| Timing misses | Filing owner (with compliance copied) | Missed reporting or payment deadlines and deadline-risk tracking |
Escalate for legal interpretation when the issue is scope, not execution. A grounded trigger is when HMRC eligibility framing, such as sole trader or landlord in Self Assessment, does not cleanly fit your operating model, or when the case looks closer to a limited-company profile. Execution defects usually stay inside the control cycle. Scope ambiguity can change what you should build in the first place.
Watch for these early warning patterns:
HMRC guidance expects corrections through the year and also says you do not need to resend the original quarterly update after a correction. If teams keep reopening the same period to rebuild prior submissions, treat that as a control failure.
Run one weekly verification check on a live exception and confirm that you can show the original record, the correction, the owner, and the decision. For timing misses, log the exact affected deadline and any transition treatment you are relying on. For unsupported software or income-source cases, follow up with the software provider, and if a new income source cannot be reported through compatible software during testing, route the case for testing-phase opt-out handling.
Treat evidence completeness as a release criterion from the start, not as post-incident cleanup. For any MTD for Income Tax process, your pack should let a reviewer see how records were created, corrected, submitted, and checked.
HMRC's published process is clear on the points you need to evidence. Create and store digital records in compatible software. Send quarterly updates every 3 months. Correct records through the year. Check information for correctness before submitting the annual return by 31 January. HMRC may also ask for information or documents during a compliance check. GOV.UK does not prescribe one internal pack format, so define one and keep it consistent.
Keep this practical baseline:
This is not paperwork for its own sake. It is how you prove that a reported figure came from known records and moved through controlled steps.
Store dated snapshots of the GOV.UK pages used at decision time. That matters because guidance changes over time, including updates shown on core MTD pages and update notices. Link each snapshot to the related decision entry so reviewers can see what guidance you relied on at that point.
Apply the same rule to internal interpretations. If legal or compliance used guidance aimed at sole traders, landlords, and agents as the closest reference, preserve that memo and label it clearly as internal interpretation, not confirmed operator scope.
Use one repeatable test: can an independent reviewer trace a reported figure back to source records without undocumented manual steps? For quarterly updates, trace the summary to underlying digital records and in-year corrections. For the annual return, show the final adjusted figure and the explicit correctness check before submission.
If evidence depends on tribal knowledge or uncontrolled files, treat it as a release blocker. Also keep the Self Assessment record trail: digital records alone are not enough if you cannot also show the original or supporting documents used to prepare the return.
Use this 90-day sequence as an internal control plan, not as an HMRC-mandated format.
Lock definitions first so scope decisions are defensible. HMRC frames MTD for Income Tax around sole traders and landlords in Self Assessment, while digital platform operator seller reporting sits in a separate HMRC regime. Keep a confirmed-versus-unknown register and track wording dependencies, including any threshold wording differences across GOV.UK pages. Assign clear ownership across legal, compliance, finance, and engineering, and require each "build now" item to map to a specific GOV.UK source.
Complete field-level lineage before committing to integration. You should be able to trace source records, in-year corrections, quarterly totals every 3 months, and annual return outputs due by 31 January without undocumented manual steps. Then choose the integration mode: software-led filing, bridging software connected to existing records, or deeper integration through software that uses HMRC APIs. Run one dry-run quarterly cycle that includes both a nil-activity period and a correction case.
Harden exception handling and finalize the evidence pack. Confirm that submission logs, decision records, exception ownership, and dated guidance snapshots are complete and reviewable. Close with a cross-functional checkpoint across compliance, legal, finance, and engineering.
If scope questions for UK platform operators remain unresolved at the final gate, move to a monitored launch and set explicit legal escalation dates. You might also find this useful: A Guide to VAT for UK Freelancers.
The practical move is disciplined execution under uncertainty: separate confirmed HMRC facts from open scope questions, then build controls you can defend either way.
HMRC presents Making Tax Digital for Income Tax as a route for sole traders and landlords to create, store, and correct digital records, send quarterly updates through compatible software, and submit the annual tax return and pay by 31 January following the year. HMRC's digital platform operator reporting is separate. Operators collect seller information yearly and send it to HMRC by the following January. If you blur those regimes, you risk the wrong cadence, ownership model, and evidence pack.
For most UK platform operators, the immediate job is not predicting future interpretation. It is making reporting traceable and adaptable now, with clear owners for interpretation, submissions, integration, and exception approval, plus a decision log that separates confirmed requirements from items parked for legal confirmation.
Use one control test across all tooling choices: can an independent reviewer trace one submitted figure back to source records, corrections, approvals, and submission evidence without undocumented manual steps? If not, API connectivity or software recognition is not enough.
Keep dates and thresholds in the right lane. HMRC sets MTD for Income Tax thresholds for sole traders and landlords at over £50,000 from 6 April 2026, over £30,000 from April 2027, and over £20,000 from April 2028. Platform reporting has its own annual timing, including registration by 31 January after the reportable year end.
Two avoidable mistakes are treating quarterly MTD rhythms as operator-reporting rules, and relying on a third party without keeping your own record of what was sent to HMRC. A defensible baseline is a confirmed-versus-unknown register, data lineage map, submission logs, exception register, remediation history, and dated copies of the GOV.UK and HMRC guidance used at decision time.
If ownership is clear, evidence is complete, and escalation is explicit, you reduce regulatory surprise without overbuilding the wrong process.
If you want a practical review of your MTD reporting flow, escalation model, and audit-trace requirements across teams, talk with Gruv.
Not based on the HMRC and GOV.UK material used here. Current public wording is framed around sole traders and landlords in Self Assessment with self-employment income, property income, or both. Treat operator-specific scope as unresolved until legal review confirms it.
Keep digital records, submit quarterly updates, and submit the annual tax return through compatible software. Quarterly updates are summaries, not final tax returns. You should also be able to trace each submitted summary back to stored records, including corrections and who made them.
Build controls that remain useful either way, such as record capture, correction history, submission logging, role ownership, and evidence retention. Monitor decisions that depend on unconfirmed operator scope, especially product or architecture choices. This helps avoid hard-coding legal assumptions you may need to reverse later.
Engineering should own API integration, sandbox testing, authentication handling, and submission-response logging. Compliance should own submission rules, review checkpoints, exception decisions, and approval of the dataset being filed. Keep both trails for the same submission: technical receipt evidence and business approval evidence.
HMRC requires commercial software that works with MTD for Income Tax, and existing digital records can be used with bridging software. That means a full system replacement may not be necessary. If you use bridging, test correction flows and nil-activity periods before treating it as production-safe.
Keep evidence that lets an independent reviewer trace figures from the submission back to source records without undocumented manual steps. In practice, keep digital records, correction history, submission logs, approvals, exception records, and dated snapshots of the GOV.UK guidance you relied on. Your pack should also show how quarterly summaries support the annual return due by 31 January following the year.
Escalate when the answer would change filing responsibility, control scope, or core architecture. Typical triggers include unresolved operator-scope questions, mixed models where sellers may also be sole traders or landlords, and conflicts across guidance artifacts. Also consider support limits, because HMRC's dedicated help here is limited to sole trader and landlord queries.
A financial planning specialist focusing on the unique challenges faced by US citizens abroad. Ben's articles provide actionable advice on everything from FBAR and FATCA compliance to retirement planning for expats.
With a Ph.D. in Economics and over 15 years of experience in cross-border tax advisory, Alistair specializes in demystifying cross-border tax law for independent professionals. He focuses on risk mitigation and long-term financial planning.
Includes 2 external sources outside the trusted-domain allowlist.
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.