Skip to content

GRA · Payments and Market Infrastructure

Spatial financeWhere capital meets hazard, exposure and transition

Resilience and finance readiness

Infrastructure readiness asks whether a payment system, central counterparty or settlement chain could keep its critical functions through a physical, operational or cyber shock, and what evidence an overseer would need to judge that. Payments and Market Infrastructure, a the Global Risks Alliance (GRA) platform, prepares dependency and site evidence and frames the questions. Oversight stays with central banks and regulators.

Open Reader questions and safeguards Back to Payments and Market Infrastructure
01ناوەڕۆک

Resilience and finance readiness in five parts.

لەم دۆسیەیەدا5 parts
  1. 01ئامادەباشیReadiness is not approval
  2. 02PFMI lensThe principles an FMI is assessed against
  3. 03Recovery objectiveThe two-hour planning objective
  4. 04ReleaseWho sees a readiness file
  5. 05سەرچاوەکانWhere this page’s references lead
02ئامادەباشی

Readiness is not approval.

A readiness file describes a programme’s evidence, risks and governance so that an institution can carry out its own review. GRA does not approve, rate, underwrite, lend or invest, and it recommends no counterparty.

See the readiness checklist
03PFMI lens

The principles an FMI is assessed against.

Principle groupExamples
Credit and liquidity riskCollateral, margin, liquidity resources for the largest participant defaults
SettlementSettlement finality, money settlement, delivery versus payment
Default managementRules and procedures, segregation and portability
General business and operational riskBusiness continuity, recovery of critical operations, cyber resilience
Access and transparencyParticipation requirements, disclosure of rules and data
04پرۆسە

چۆن پرۆسەکە کار دەکات.

Process explorer · Process

Resilience and finance readiness: Payment from instruction to finality

8 هەنگاو4 قۆناغ

پرۆسە

Resilience and finance readiness: Payment from instruction to finality

An RTGS system checks a payment, queues it if funds are short, settles it gross in real time and gives final settlement.

  1. 01 وەرگرتن

    1. 01Payment instructionSource · ParticipantThe system should use, or at least accommodate, relevant internationally accepted communication procedures and standards.
    2. 04Validity and conditionality checksStep · System operatorA payment is accepted once it passes validity and conditionality checks, such as funds or credit. An invalid payment is generally rejected.

  2. 02 Settlement

    1. 02LiquidityDataset · ParticipantParticipants need liquidity for outgoing payments: central or commercial bank balances, incoming payments and intraday credit.
    2. 05QueueModel · System operatorA valid payment that fails conditionality checks is queued or rejected. Queuing and other liquidity-saving tools can cut liquidity needs.
    3. 06Settle in real time, grossStep · System operatorRTGS settles payments continuously, without deferral, usually one by one. Money settlements should use central bank money where practical.

  3. 03 Finality

    1. 07Final settlementRecord · System operatorThe system gives clear, certain final settlement by the end of the value date at least, intraday or real time where needed.
    2. 08ReconciliationStep · System operatorReconciliation checks that records issued by two different entities match. The pages read state no timing for payment سیستەمەکان.

  4. 04 Resilience

    1. 03Business continuity and secondary siteExercise · System operatorThe plan uses a secondary site and aims to resume critical IT within two hours and settle by end of day. Arrangements are regularly tested.

Outline of an external standard or method, from its public sources. It describes what the framework says, not a record of any run. It does not show that Nexus or any partner performs, certifies or approves a step. A gate is a step of the method, never a Nexus approval. The source is the CPMI-IOSCO Principles for financial market infrastructures. A business continuity plan covers disruption.

05Recovery objective

The two-hour planning objective.

CPMI-IOSCO cyber guidance asks FMIs to plan to resume critical operations within two hours of a disruption and to complete settlement by the end of the day, even in extreme but plausible scenarios. Readiness evidence documents site geography, power and network diversity against that objective. Topic depth at clearing and settlement.

06Release

Who sees a readiness file.

A file is released only at the programme owner’s written direction, to a party the owner chooses, with no fee tied to any transaction.

07سەرچاوەکان

Where this page’s references lead.

ئەو لەش و بەڵگەنامانەی ئەم لاپەڕەیەیان لەگەڵ دەخوێنرێتەوە. دۆخ و وەشانەکان دەگۆڕێن؛ هەر بەستەرێک دەچێتە لای لەشی دەرکەر.

08لاپەڕەکان

Pages in Resilience and finance readiness.

لاپەڕە

Reader questions and safeguards

09پرسیارەکان

پرسیار و وەڵام.

Does a readiness file mean finance is available?
No. It supports an independent review by the competent institution, which decides under its own rules.
پارەدان و ژێرخانی بازاڕ

Bring an exposure or capital question to the Alliance.

زانیاری و پرسیار ئەمڕۆ کراوەن. پرسیارێک ژمارەی ئاماژەی پێدەدرێت و هەنگاوی دواتر دیاری دەکات؛ داواکاری، پارەدان، تەرخانکردنی کۆمپیوتەر و تۆمارکردن تەنیا کاتێک دەکرێنەوە کە تیم، مەرج و توانای پێداچوونەوەیان هەبێت.

Propose a readiness pilot بینینی هەموو ڕێگاکانی پەیوەندی
یاسایی

نەخشە، داتا و وێنەکانی ئەم ماڵپەڕە بۆ ناوەڕۆک و زانیاریی گشتی پیشان دراون. ئامۆژگاری، پێشبینی یان ئاگادارکردنەوە نین؛ سنوورەکانی زانیارییەکە لە ڕەتکردنەوەی بەرپرسیارێتی و ئاگاداریی داتادا دەستنیشان کراون.