GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX

Articles / Learning brief

High-value payments and HVPS+

Your notes

What this means in plain language

High-value payment systems are usually central-bank real-time gross settlement systems that settle large payments individually and with finality. The HVPS+ (High Value Payments Plus) guidelines align how ISO 20022 messages are used across them, so a payment reads the same across borders.

A high-value payment system moves large, time-critical payments between banks, and most are run by a central bank as an RTGS (real-time gross settlement) system. Real-time gross settlement means each payment is settled on its own, one by one, the moment it is processed, and once settled it is final and cannot be reversed. Because these systems sit at the centre of a currency, they handle the largest and most urgent transfers. As they adopt ISO 20022 (International Organization for Standardization standard 20022), a risk appears: each system could fill in the new messages slightly differently. HVPS+ (High Value Payments Plus) is a set of market-practice guidelines that answers this by describing exactly how ISO 20022 messages should be populated in high-value systems. When every real-time gross settlement system follows the same guidelines, a payment carries the same fields in the same places whichever system it passes through, which keeps data intact and processing automatic as a payment crosses borders.

Understand the full idea, step by step

Most of the payments in this course are small enough to wait a beat — a batch tonight, a credit in the morning. But some are not. When a bank settles a market trade or moves a very large sum, waiting is the risk. For those, an economy runs a different kind of system, built for certainty rather than cost.

RTGSreal-time gross settlement

A high-value payment system is usually a central bank's RTGS system. Gross means each payment settles on its own, in full, rather than being bundled and offset against others. Real-time means settlement happens as the payment is processed, not at day's end. Funds move in central-bank money, and once settled the transfer is final and irrevocable — which is the whole reason these systems exist.

Central Bank Omega's RTGS books
AccountDrCr
Bank Alfa's settlement accountUSD 2,500,000.00
Nordbank's settlement accountUSD 2,500,000.00

Illustrative two-entry view of one gross settlement. A real system also manages each bank's intraday liquidity, queues, and reservations; the account structure is simplified here.

If each payment settles on its own in full, where does the money come from at the exact moment it settles?

That is the trade-off of gross settlement. Because payments are not netted, each one needs enough funds available in the paying bank's settlement account the moment it settles. So banks manage their liquidity through the day — watching what is coming in against what must go out, and sometimes queuing a payment until cover arrives. Netting many payments and settling only the balance uses less liquidity, which is why it suits lower-value traffic; but for large, urgent value, gross settlement with finality is worth the liquidity it demands.

One standard, many systems, the same divergence risk

As high-value systems replace older message formats with ISO 20022, each faces the same choice about how to fill in the new messages — and left alone, each could choose differently. That is the same divergence problem CBPR+ solves for cross-border payments, now appearing inside each domestic system. The answer is the same kind of tool: a shared market practice that narrows the base standard to one agreed way of populating each message.

HVPS+High Value Payments Plus

HVPS+ is a set of market-practice guidelines — developed by central banks, market infrastructures, and commercial banks through the industry's Payments Market Practice Group alongside SWIFT — for how ISO 20022 messages should be used in high-value systems. It states which elements are used and mandatory, how parties and amounts are structured, and which code lists apply. HVPS+ runs no payment system itself; it is a shared reference each operator adopts.

CBPR+ and HVPS+ — aligned, but for different legs
CBPR+HVPS+
Which legCross-border interbank, over SWIFTDomestic high-value systems (RTGS)
Who agrees itCorrespondent-banking community via PMPG/SWIFTCentral banks and market infrastructures via PMPG/SWIFT
What it narrowsISO 20022 for cross-border payments and reportingISO 20022 for high-value settlement messages
RelationshipDeliberately aligned so data carries at the boundaryDeliberately aligned so data carries at the boundary

Alignment across borders

The payoff shows most clearly where a payment crosses between systems. A cross-border payment often travels over a correspondent relationship formatted to CBPR+, then lands in a domestic RTGS system to reach the final bank. If the two practices described their messages differently, data would have to be reshaped at the boundary — and reshaping is where structured detail is lost and manual repair begins. HVPS+ is deliberately aligned with CBPR+ so a structured address, a purpose code, or a party identifier populated for the cross-border leg carries into the domestic leg without being rebuilt.

STRICTLY SPEAKING

Strictly speaking, this harmonisation is never quite total. Each high-value system keeps some local rules, and every operator publishes its own specific usage guidelines that a participant must still follow. The direction is steady convergence on one shared way of expressing a high-value payment — not a single identical message everywhere.

FOR NOW, REMEMBER

  • A high-value system carries the largest, most time-sensitive payments — usually a central bank's RTGS, settling each payment on its own, in full, and with finality.
  • Gross settlement gives certainty but demands intraday liquidity, because each payment needs cover at the moment it settles.
  • HVPS+ is the market practice that narrows ISO 20022 for high-value systems, the same kind of tool CBPR+ is for cross-border.
  • HVPS+ is deliberately aligned with CBPR+ so data survives the boundary between a cross-border leg and a domestic RTGS leg.

TRY IT YOURSELF

Bank Alfa's USD 2,500,000.00 payment to Nordbank has settled in Central Bank Omega's RTGS system this morning. An hour later Bank Alfa realises it sent to the wrong counterparty. What is true about that settled payment?

It settled in central-bank money with finality, so it cannot simply be unwound — recovering the funds means a fresh return payment, with the counterparty's cooperation.

Correct — Right. Finality is the defining property of RTGS: once settled, the transfer is irrevocable. There is no reversal of the settlement itself; the money can only come back as a new, separate payment if Nordbank agrees.

Because settlement is real-time, it can be cancelled in real time up to the end of the day.

Not this one — Real-time describes when settlement happens, not a window to undo it. Gross settlement with finality is designed precisely so a settled payment cannot be pulled back — that certainty is the point of the system.

It was netted with other payments, so the error nets out against Bank Alfa's other flows overnight.

Not this one — High-value RTGS settles gross, not net — this payment settled on its own, in full. There is no overnight netting to absorb the error.

SWIFT MT and ISO 20022 are the standards this course lives in — but they are not the only ones. Next, a short map of the other message families worth recognising, from card messaging to national file formats.

KEEP GOING

Three things to remember

  1. 01

    A high-value payment system is usually a central-bank RTGS (real-time gross settlement) system that settles large payments individually and with finality.

  2. 02

    HVPS+ (High Value Payments Plus) is a market-practice guideline for how ISO 20022 messages are populated in high-value systems.

  3. 03

    Shared guidelines make a payment carry the same fields in the same places across different systems, protecting data and automation.

Where you would use this

USE CASE 01

A central bank operating an RTGS system adopts HVPS+ so its ISO 20022 messages match the market practice used by other high-value systems.

USE CASE 02

A bank's payments team builds one ISO 20022 implementation that works across several HVPS+-aligned systems rather than a different one for each.

USE CASE 03

A correspondent bank relies on consistent HVPS+ fields so a cross-border payment entering a domestic system needs no manual repair.

Put the idea into a real situation

Illustrative example: a fictional bank, Meridian Trust, must settle a EUR 4,750,000.00 interbank payment to a fictional counterparty, Kestrel Union Bank, on the same day. It sends the payment into a central-bank RTGS (real-time gross settlement) system as an ISO 20022 pacs.009 message formatted to HVPS+ (High Value Payments Plus) guidelines. The system settles the full EUR 4,750,000.00 individually and finally in central-bank money within 30 seconds, with no netting against other payments. Because the same HVPS+ field usage matches the CBPR+ cross-border guidelines the payment followed on its earlier leg, the structured parties and amounts carry across the boundary unchanged, and Kestrel Union Bank books the funds without a repair step.

Evidence & review

REVIEWED 2026-07-13

Domestic high-value payment systems (usually central-bank RTGS) adopting ISO 20022 under HVPS+ market practice, and their alignment with CBPR+ for cross-border.

What this brief simplifies: RTGS settlement and liquidity are shown in a two-entry teaching ledger; queues, reservations, and intraday liquidity mechanics are named but not modelled. No volumes or thresholds are quoted. Named parties are fictional teaching cast.

Sources for this brief4
  1. Market practice

    High Value Payments Systems Plus (HVPS+) usage guidelinesHVPS+ task force (published by Swift) · ISO 20022 usage in high-value systems

    Provides the common ISO 20022 usage-guideline base that high-value payment systems such as T2, CHAPS, Fedwire, and CHIPS adapt for their own specifications, supporting interoperability with CBPR+. · Checked 2026-07-12

    Full guidelines are published on MyStandards; content here relies on public summaries.

  2. Market practice

    Cross-Border Payments and Reporting Plus (CBPR+) usage guidelinesSwift (CBPR+ working group) · Cross-border alignment with HVPS+

    Defines how ISO 20022 messages (including pacs.008, pacs.009, pacs.002, pacs.004, and camt investigation messages) are used and validated for cross-border payments on the Swift network. · Checked 2026-07-12

    Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.

  3. Official requirementMarch 2003 edition

    A glossary of terms used in payments and settlement systemsCPSS (now CPMI), Bank for International Settlements · RTGS, gross settlement, settlement finality

    Standard definitions for payment, clearing, and settlement terminology used across BIS committee reports and referenced by glossary entries on this site. · Checked 2026-07-12

    Terminology has evolved since this edition; newer CPMI publications refine some definitions.

  4. Scheme-specific rule

    CHAPSBank of England · Operator-specific high-value usage guidelines

    Describes CHAPS, the UK's sterling high-value payment system, settled payment by payment in the Bank of England's RTGS infrastructure. · Checked 2026-07-12

    The Bank of England has operated CHAPS directly since November 2017; participant-facing reference documents are published separately.

Learn this properly

Related briefs

View Articles archive

The real cost of payments

Uses a hypothetical bank and transaction volumes to estimate the operating economics and potential profitability of domestic and cross-border payment services.

READ BRIEF

CBPR+: ISO 20022 for cross-border payments

CBPR+ (Cross-Border Payments and Reporting Plus) is a set of usage guidelines that apply ISO 20022 to cross-border interbank payments over SWIFT, defining exactly how each message field is populated during and after the MT-to-MX transition.

READ BRIEF