PvP Link and Settle
Instant Payment vs Payment (PvP) of two currencies on Settlement Fabric
Overview
Link and Settle allows two participants to instantly PvP settle two currencies once a trade has been agreed between them.
Process
Two participants execute a trade and confirm settlement details (i.e. settlement amounts) - this process happens outside of the RTGS.global network
Each send their settlement requests to RTGS.global Settlement Fabric, which performs payload validation checks on the requests
RTGS.global links the two requests using LinkIdentifiers* (these are unique trade IDs / references agreed during the confirmation process)
RTGS.global's Settlement Fabric then conducts instant atomic settlement, debiting and crediting the participants' networks accounts as per request instruction
When settlement completes, both participants are notified of the credit / debit transactions via a camt.054 notification of credit/debit
Network account balances are updated in real time
Link and Settle status notifications (pacs.002) are sent whenever the state of a request changes (i.e. from LinkPending to LinkCreated). A list of the request states are provided below. *Link Identifiers are stored and used in the Link and Settle service logic and therefore should not contain any personal information, financial or commercially sensitive information, or other credentials. RTGS.global is committed to ensuring the security and protection of any personal or commercial information that we process, and to provide a compliant and consistent approach to data protection.
Link and Settle example
Use Case (for diagram below)
EU Bank and US Bank execute and confirm a €/$ FX trade (using existing upstream platforms / processes).
After confirmation, both participants independently send their settlement instructions to RTGS.global, quoting the same Link identifier(s).
Settlement Fabric links the two requests and performs instant atomic settlement on the participants' network accounts.
Payment Status Notifications (pacs.002) for Link & Settle
Every time there is an update to the status of a Link & Settle request, a pacs.002 notification is published.
The TransactionStatus and StatusReasonInformation are included in the pacs.002. The TransactionStatus' are:
ACCC: AcceptedSettlementCompletedCreditorAccount, used when a Link Request is settled
ACSP: AcceptedSettlementInProcess, used when two requests have been linked
PDNG: Pending, used when a request has not yet been linked
RJCT: Rejected, used when a request has been irrevocably rejected, requiring a new request to be created
Below are the possible TransactionStatus and StatusReasonInformation messages for the Link & Settle process:
| ISO Status | ISO Reason Code | Proprietary Reason | ISO Code Name | Usage |
|---|---|---|---|---|
ACCC | LinkSettled | Request completed - All debits / credits are settled to accounts | ||
ACSP | LinkCreated | Link is created (2 requests are linked by Link Identifiers and Counterparties) | ||
PDNG | LinkPending | Requires counterparty to send a request with the same Link Identifiers | ||
PDNG | LinkRequest | A link has been submitted by a counterparty which requires the participant to submit a matching link | ||
ACWP | OwnInsufficentFunds | Requires the participant to fund their own account | ||
ACWP | CounterpartyInsufficentFunds | Requires the counterparty to fund their account | ||
RJCT | DU03 | DuplicateTransaction | Link Identifiers have already been used in a request which is pending | |
RJCT | RF01 | NotUniqueTransactionReference | UETR of request is not unique | |
RJCT | AC02 | InvalidDebtorAccountNumber | The network account (debtor account) is not owned by the participant | |
RJCT | AC03 | InvalidCreditorAccountNumber | The network account (creditor account) is not owned by the participant | |
RJCT | AC10 | InvalidDebtorAccountCurrency | The currency of the debtor account is not enabled for the debit currency | |
RJCT | AC11 | InvalidCreditorAccountCurrency | The currency of the creditor account is not enabled for the credit currency | |
RJCT | CounterpartyNotFound | Counterparty in request cannot be found | ||
RJCT | OwnIdentifierInCounterpartyField | The participant has provided their own BIC or LEI in the counterparty field | ||
RJCT | CounterpartiesMismatch | A link cannot be created because the counterparties in the requests do not match | ||
RJCT | AM09 | WrongAmount | The credit / debit amounts specified by each participant do not match within the tolerance | |
RJCT | CurrencyMismatch | Currencies in requests do not match | ||
RJCT | ValidationFailed | Request signature validation failed |
Insufficient Funds
Where a Link and Settle request could not be atomically settled because one or more of the participants has insufficient funds on their debit account, both participants will be notified, and the request will move to a retry queue.
Retry will be attempted when an event occurs on the debit account which would have an effect on the available balance:
A credit to the account
A cancellation of another pending debit
Retries will be held in the retry queue until a credit triggers a successful settlement, or the requests are cancelled by respective participants.
Last updated
