Set-up Models: Liquidity and Infrastructure Provisioning

Transcription

1 Set-up Models: Liquidity and Infrastructure Provisioning Ripple's flexible payments solution for banks, xcurrent, provides the ability to modernize settlement and messaging for cross-border payments. xcurrent also enables our customers to adapt to the unique liquidity and infrastructure needs of their financial institution. This document overviews Ripple's supported set-up models, which include different ways of provisioning liquidity and infrastructure for cross-border payments on RippleNet. The supported set-up models demonstrate how the following liquidity and infrastructure relationships and entities are included in various xcurrent deployments: Direct liquidity relationships Credit relationships Third-party liquidity providers Payment providers Service bureaus Correspondent banks This document provides detailed information regarding how cash settlement mechanisms work in coordination with xcurrent s real-time ledger updates. This document focuses on the following key components across all the supported set-up models: Account sequence for flow of funds: The money movement across various accounts at the transacting banks Funding mechanism: The different liquidity provisioning arrangements impact on the various set-up models Technology required: The required components of xcurrent (, Ledger, and ) for each transacting party

2 Liquidity Set-up Model a: This model is utilized when the originating bank provides FX liquidity at the beneficiary bank. funds are transferred from the originator's account to the originating bank s treasury account (). s of both banks are simultaneously updated with a credit of the transaction amount to the beneficiary bank. The funds are then transferred from the originating bank s nostro account to the beneficiary's account (). For the funding mechanism, the originating bank prefunds its nostro in the beneficiary country s currency via bulk FX purchase through a onetime, out-of-band transaction. Regarding the technology required, as the liquidity provider, the originating bank requires,, and. The beneficiary bank requires and. Nostro Account - Prefunded nostro account - Prefund and redemption via bulk FX purchase

3 Liquidity Set-up Model b: This model is utilized when the beneficiary bank provides FX liquidity at the originating bank. funds are transferred from the originator's account to the beneficiary bank s nostro account (). s of both banks are simultaneously updated with a credit of the transaction amount to the beneficiary bank. The funds are then transferred from the beneficiary bank s treasury account to the beneficiary's account (). For the funding mechanism, the beneficiary bank establishes a nostro/vostro relationship with the originating bank (money stays with beneficiary bank and is being held on behalf of the originating bank for local pay out). Nostro Account - Nostro account setup - Redemption via bulk FX transaction 3

4 Credit Lines Set-up Model c: This model is utilized when the transacting banks have established a credit line with one another. funds are transferred from the originator's account to the originating bank s treasury account (). Each bank s credit position is then updated on both bank s s with their respective debits and credits based on the exact transaction amount (). The funds are then transferred from the beneficiary bank s treasury account to the beneficiary's account (3). For the funding mechanism, both transacting banks establish a credit relationship based on either daily or credit limit settlement. Regarding the technology required, each transacting bank runs all components:,, FX Ticker and. 3 Credit Line for Beneficiary Bank Credit Line for Originating Bank FUNDS FLOW: - Credit line at each transacting bank - Settled on deferred net basis 4

5 Payment Provider and Non-Ripple-enabled Beneficiary Set-up Model a: This model is utilized when the originating bank provides liquidity and a payment provider is leveraged for paying out to the beneficiary bank. funds are transferred from the originator's account to the originating bank s treasury account (). s of the originating bank and payment provider are simultaneously updated with a credit of the transaction amount. The payment provider then sends a payment directly to the beneficiary s account through local rails (). For the funding mechanism, the originating bank opens an account with the payment provider, prefunding it in the beneficiary country s currency. The payment provider utilizes local rails to pay out to the beneficiary bank. Regarding the technology required, as the liquidity provider, the originating bank requires,, and. The payment provider requires Ledger and. PAYMENT PROVIDER (EUR) Account with Payment Provider REQUIRED COMPONENTS OF xcurrent NOT RIPPLE-ENABLED LOCAL RAIL FLOW Prefunding from originating bank to payment provider in beneficiary s currency via bulk FX purchase Payment delivery from payment provider s bank account to beneficiary s account via local rails 5

6 Service Bureau and Payment Provider Set-up Model b: This model is utilized when the originating bank provides liquidity, requires a service bureau to host their xcurrent instance and leverages a payment provider to pay out to the beneficiary bank. funds are transferred from the originator's account to the originating bank s treasury account (). s of the originating bank and payment provider are simultaneously updated with a credit of the transaction amount. The payment provider then sends a payment directly to the beneficiary s account from the originating bank s account at the payment provider (). For the funding mechanism, the originating bank opens an account with the payment provider prefunding it in the destination currency. The payment provider utilizes local rails to pay out to the beneficiary bank. Regarding the technology required, since the originating bank is the liquidity provider, the service bureau requires,, and (all of which would be hosted on behalf of the originating bank). The payment provider requires and. SERVICE BUREAU PAYMENT PROVIDER (EUR) Account with Payment Provider REQUIRED COMPONENTS OF xcurrent NOT RIPPLE-ENABLED LOCAL RAIL FLOW Prefunding from originating bank to payment provider in beneficiary s currency via bulk FX purchase Payment delivery from payment provider s bank account to beneficiary s account via local rails 6

7 Third-party Liquidity Set-up Model 3: This model is utilized when transacting banks elect to use a third-party liquidity provider. funds are transferred from the originator's account to the liquidity provider s GBP account at the originating bank (). The balance of the liquidity provider s GBP account at the originating bank is updated with a debit of the transaction amount. Simultaneously, the liquidity provider s EUR account at the beneficiary bank s is updated with a credit of the transaction amount. The funds then move from the liquidity provider s EUR account to the beneficiary s account (). For the funding mechanism, the liquidity provider opens an account with both transacting banks prefunding them in their respective local currencies. Regarding the technology required, the originating bank requires and. The beneficiary bank requires and. Since the liquidity provider is only serving to provide liquidity rather than acting as an intermediary, it requires FX Ticker and. LIQUIDITY PROVIDER REQUIRED COMPONENTS OF xcurrent Liquidity Provider s GBP Account Liquidity Provider s EUR Account Prefunding from liquidity provider s bank account to originating bank via local rails Prefunding from liquidity provider s bank account to beneficiary bank via local rails 7

8 Correspondent Banking (Q 08) Set-up Model 4: This model is utilized when transacting banks leverage a common correspondent banking relationship. funds are transferred from the originator's account to the correspondent bank s nostro account at the originating bank (). s of all banks are simultaneously updated to reflect a credit of the transaction amount to the beneficiary bank (). The funds then move from the beneficiary bank s treasury account to the beneficiary s account (3). For the funding mechanism, the originating bank establishes a liquidity relationship with the correspondent bank (the funds remain in the correspondent bank s treasury account to enable pay out to the beneficiary bank). The beneficiary bank establishes a liquidity relationship with the correspondent bank (seen here as a nostro account at the correspondent bank, which is prefunding liquidity at the beneficiary bank). Regarding the technology required, the originating bank requires,, and. The correspondent bank requires and. The beneficiary bank requires,, and. CORRESPONDENT BANK (EUR) Nostro Account 3 Nostro Account LOCAL RAIL FLOW FUNDING MECHANISM Account relationship between originating bank and correspondent bank FUNDING MECHANISM Account relationship between beneficiary bank and correspondent bank