National Payments System - Transfers - Complementary Rules. National Payments System - Payment Services. Adjustments

2026 - YEAR OF ARGENTINE GREATNESS

COMMUNICATION "A" 8508
05/11/2026

TO FINANCIAL INSTITUTIONS,
TO ELECTRONIC CLEARING CHAMBERS,
TO THE ADMINISTRATORS OF ELECTRONIC FUND TRANSFER PAYMENT SCHEMES OF FUNDS, TO PAYMENT SERVICE PROVIDERS THAT OFFER PAYMENT ACCOUNTS:

Ref.: Circular
SINAP 1-260:

National Payments System - Transfers - Complementary Rules. National Payments System - Payment Services. Adjustments. ___________________________________________________________________________

We are writing to inform you that this Institution adopted the resolution which, in its relevant part, provides:

"1 - Replace item 1.2.6. of the consolidated text on National Payments System – Transfers – Complementary Rules with the following:

"1.2.6. Interoperable ecosystem: every instant transfer scheme shall interoperate with the rest of the instant transfer schemes so that its participants can originate transfers destined to any other account provider – financial institution or PSPCP – that is not a participant, under the same conditions in terms of service level as a transfer that is settled within the scheme itself.

This implies that, even if the schemes that administer the originating and receiving entities have different rules (messaging, guarantees, fraud control, etc.), instant transfers shall be processed in accordance with the rules of the scheme responsible for each stage of the transaction flow."

2 - Replace item 2.4. of the consolidated text on National Payments System – Payment Services with the following:

"2.4. The low-value electronic clearing chamber (CEC-BV) shall operate and administer the CVU database.

In order to access the services offered by the CEC-BV in relation to the CVU, PSPs shall connect through at least one financial institution (sponsoring bank)."

3 - Establish that the low-value clearing chamber (CEC-BV) shall, free of charge, make available to the administrators of electronic fund transfer payment schemes authorized by the Central Bank of the Argentine Republic replicas of the CVU database and of the unique registry of alias–CBU and alias–CVU correspondences. Subse-

quently to the initial massive replication, which shall be carried out on 15/02/27, additions, deletions and modifications shall be transmitted by means of 2 (two) mechanisms:

• An online interface so that such administrators can receive that information synchronously, effective from 31/03/27.

• A daily file containing the entirety of the additions, deletions and modifications of that day, effective from 15/02/27.

The definitions necessary for the performance of this function – additional to those already provided for in item 3.7.1. of the consolidated text on National Payments System – Payment Services – shall be adopted by the BCRA, following a non-binding consultation carried out within the framework of the Interbank Commission for Payment Means of the Argentine Republic (CIMPRA) to Cámara Electrónica de Compensación SA (COELSA), Red Link SA and Newpay SAU, as well as to the remaining actors whose participation it deems appropriate.

The obligation to access the alias database established in item 3.9. of the consolidated text on National Payments System – Payment Services may be complied with by consulting these replicas.

4 - Provide, effective from 06/04/27, that the administrators of instant transfer schemes shall comply with the interoperable operational flows between the schemes administered by Red Link SA or Newpay SAU and COELSA, for each use case of push and instant transfers described in the Annex and which constitute the Standardized Payment Interface, which shall be subject to the following premises:

a) For each transaction, the guarantee of the scheme that debits the account, or the one established by the Standardized Payment Interface, shall be considered.

b) Financial institutions – including in their role as sponsoring entities of payment service providers that offer payment accounts – shall be able to receive immediate credits from any administrator of an instant transfer scheme.

c) Financial institutions and payment service providers that offer payment accounts may choose a single administrator/scheme through which they will receive and originate all instant transfers.

5 - Repeal the content of items 15. and 16. of Communication A 6423.

6 - Replace Section 4. "Standardized Payment Interface (SPI)" of the consolidated text on National Payments System – Transfers – Complementary Rules with the following:

"4.1. The Standardized Payment Interface (SPI) shall contain the interoperability, guarantee, messaging and other information exchange procedure rules, such as application programming interfaces (API), of the instant transfer schemes.

4.2. The definitions necessary for the implementation of the SPI – including a Service Level Agreement (SLA) – shall be specified by the BCRA, following a non-binding consultation within the framework of the CIMPRA with the actors it deems relevant".

3- 7 - Replace item 2.5. of the consolidated text on National Payments System – Transfers – Complementary Rules with the following: "2.5. Confirmation messaging: the financial institution shall notify the ordering client in accordance with what is provided for in the Standardized Payment Interface. The information displayed to customers regarding the transactions carried out by them, including messaging and the identification of the services available in the interfaces that the financial institutions and PSPCPs covered provide to their customers, shall not use the terms DEBIN and CREDIN (or similar) to identify immediate pull and push transfers or the remaining operations included in the transfer modalities specified in Section 3.” 8 - Establish that the CEC-BV shall, free of charge, make available to the administrators of immediate transfer schemes an automated programming interface (API) that provides online information on the advances and returns of guarantees linked to immediate transfer operations as provided in Section 9. of the consolidated text on the National Payment System – Electronic Clearing Houses. We send you our kind regards. CENTRAL BANK OF THE ARGENTINE REPUBLIC Jorge A. M. Golla Matías A. Gutiérrez Girault Signature 2 Manager of Payment Systems Principal Manager of Payment Systems and Current Accounts Functional Position ANNEX

B.C.R.A.
Annex to
Com. “A”
8508

1. Analysis of scenarios/push transactions

1.1. LINK/NEWPAY bank sends funds to a COELSA bank – Forced credit

1.2. LINK/NEWPAY PSP sends funds to a COELSA PSP – Forced credit

1.3. LINK/NEWPAY PSP sends funds to a COELSA bank – Forced credit

1.4. LINK/NEWPAY bank sends funds to a COELSA PSP – Forced credit

1.5. COELSA bank sends funds to a LINK/NEWPAY bank – Forced credit

1.6. COELSA PSP sends funds to a LINK/NEWPAY PSP – Forced credit

1.7. COELSA PSP sends funds to a LINK/NEWPAY bank – Forced credit

1.8. COELSA bank sends funds to a LINK/NEWPAY PSP – Forced credit

It is clarified that, in all flows, the administrator and processor are always the same entity.

1.1. LINK/NEWPAY bank sends funds to a COELSA bank – Forced credit

Process for the case in which a push transfer is initiated from a channel of a bank operating with LINK/NEWPAY to send funds to a bank operating with COELSA.

1.1.1. Transactional flow

1.1.2. Successful path

In bold: interaction points between administrators.

0 – The LINK/NEWPAY bank initiates a push transfer (ownership query).

1 – The LINK/NEWPAY processor performs the destination CBU ownership query to the COELSA administrator.

2 – Response from the COELSA administrator (CBU).

3 – Response from the LINK/NEWPAY processor to the LINK/NEWPAY bank.

4 – The LINK/NEWPAY bank initiates the push transfer (transfer).

5 – The LINK/NEWPAY processor receives the request and sends a debit request to the LINK/NEWPAY source bank.

A. The LINK/NEWPAY source bank performs the balance validation - authorizes the debit.

6 – The LINK/NEWPAY source bank confirms the debit to the LINK/NEWPAY processor

7 – The LINK/NEWPAY processor:

A.
Performs and notifies the credit to the COELSA administrator (ISO 8583 messaging).
COELSA responds with an ACK to the LINK/NEWPAY processor.
B.
Responds to the LINK/NEWPAY bank.
8 – The COELSA administrator receives the credit and performs the forced credit at the destination bank COELSA.

1.1.3. Unsuccessful path

Credits will be forced, both by LINK/NEWPAY and by COELSA. In the event that the ACK is not received from COELSA for the credit notification from LINK/NEWPAY in the ISO messaging, the sending of the notice will be retried for up to 24h and the operation will be reported at the end of the compensation day in the reconciliation file.

CENTRAL BANK OF THE ARGENTINE REPUBLIC

1.2. LINK/NEWPAY PSP sends funds to a COELSA PSP – Forced credit

Process for the case in which a push transfer is initiated from any channel of a PSP that operates with LINK/NEWPAY to send funds to a PSP that operates with COELSA.

1.2.1. Transactional flow

1.2.2. Successful path

In bold: interaction points between administrators.

0 – The LINK/NEWPAY PSP initiates a push transfer (CBU and CVU account holder inquiry).

1 – The LINK/NEWPAY administrator performs the destination CVU account holder inquiry to the COELSA administrator.

2 – Response from the COELSA administrator (CVU).

3 – The LINK/NEWPAY administrator performs the CBU account holder inquiry to the COELSA administrator.

4 – Response from the COELSA administrator (CBU).

5 – Response from the LINK/NEWPAY administrator to the LINK/NEWPAY PSP.

6 – The LINK/NEWPAY PSP performs the debit in the CVU.

7 – The LINK/NEWPAY PSP initiates the push transfer (transfer).

8 – The LINK/NEWPAY administrator receives the request and sends a push transfer request to the LINK/NEWPAY processor.

9 – The LINK/NEWPAY processor sends a debit request to the originating bank of LINK/NEWPAY.

A. The LINK/NEWPAY originating bank performs balance validation - authorizes debit.

10 – The LINK/NEWPAY originating bank confirms the debit to the LINK/NEWPAY processor.

12 – The LINK/NEWPAY processor:

A. It performs and notifies the credit to the COELSA administrator (ISO 8583 messaging). COELSA responds with an ACK to the LINK/NEWPAY processor.

B. It responds to the LINK/NEWPAY administrator.

C. The LINK/NEWPAY administrator responds the operation to the LINK/NEWPAY PSP.

D. The COELSA administrator receives the credit and performs the forced credit at the COELSA destination bank.

13 – The COELSA administrator notifies the push credit to the COELSA PSP.

1.2.3. Unsuccessful path

The credits will be forced, both by LINK/NEWPAY and by COELSA. In the event that the ACK is not received from COELSA for the LINK/NEWPAY credit notification in the ISO messaging, the sending of the notice will be retried for up to 24h and the operation will be reported at the end of the compensation day in the reconciliation file.

1.3. LINK/NEWPAY PSP sends funds to a COELSA bank – Forced credit

Process for the case in which a push transfer is initiated from any channel of a PSP that operates with LINK/NEWPAY to send funds to a bank that operates with COELSA.

1.3.1. Transactional flow

1.3.2. Successful path

In bold: interaction points between administrators.

0 – The LINK/NEWPAY PSP initiates a push transfer (CBU and CVU account holder inquiry).

1 – The LINK/NEWPAY administrator performs the destination CBU account holder inquiry to the COELSA administrator.

2 – Response from the COELSA administrator.

3 – Response from the LINK/NEWPAY administrator to the LINK/NEWPAY PSP.

4 – The LINK/NEWPAY PSP performs the debit on the CVU.

5 – The LINK/NEWPAY PSP initiates the push transfer (transfer).

6 – The LINK/NEWPAY administrator receives the request and sends a push transfer request to the LINK/NEWPAY processor.

7 – The LINK/NEWPAY processor sends a debit request to the LINK/NEWPAY originating bank.

A. The LINK/NEWPAY originating bank performs the balance validation - authorizes debit.

8 – The LINK/NEWPAY originating bank confirms the debit to the LINK/NEWPAY processor.

9 – The LINK/NEWPAY processor:

A.
It performs and notifies the credit to the COELSA administrator (ISO 8583 messaging).
COELSA responds with an ACK to the LINK/NEWPAY processor.

B. It responds to the LINK/NEWPAY administrator.

C. The LINK/NEWPAY administrator responds the operation to the LINK/NEWPAY PSP.

10 – The COELSA administrator receives the credit and performs the forced credit at the COELSA destination bank.

11 – The COELSA administrator notifies the push credit to the COELSA PSP.

1.3.3. Unsuccessful path

The credits will be forced, both by LINK/NEWPAY and by COELSA. In the event that the ACK is not received from COELSA for the LINK/NEWPAY credit notification in the ISO messaging, the sending of the notice will be retried for up to 24h and the operation will be reported at the end of the compensation day in the reconciliation file.

CENTRAL BANK
OF THE ARGENTINE REPUBLIC

1.4. LINK/NEWPAY bank sends funds to a COELSA PSP – Forced credit

Process for the case in which a push transfer is initiated from any channel of a bank that operates with LINK/NEWPAY to send funds to a PSP that operates with COELSA.

1.4.1. Transactional flow

1.4.2. Successful path

In bold: interaction points between administrators.

0 – The LINK/NEWPAY bank initiates a push transfer (CBU and CVU account holder inquiry).

1 – The LINK/NEWPAY processor performs the destination CVU account holder inquiry to the COELSA administrator.

2 – Response from the COELSA administrator (CVU).

3 – The LINK/NEWPAY processor performs the CBU account holder inquiry to the processor of the PSP's bank.

4 – Response from the COELSA administrator (CBU).

5 – Response from the LINK/NEWPAY processor to the LINK/NEWPAY bank.

6 – The LINK/NEWPAY bank initiates the push transfer (transfer).

7 – The LINK/NEWPAY processor receives the request and sends a debit request to the LINK/NEWPAY originating bank.

A. The LINK/NEWPAY originating bank performs the balance validation – authorizes debit.

9 – The LINK/NEWPAY originating bank confirms the debit to the LINK/NEWPAY processor.

10 – The LINK/NEWPAY processor:

A. It performs and notifies the credit to the COELSA administrator (ISO 8583 messaging). COELSA responds with an ACK to the LINK/NEWPAY processor.

B. It responds to the LINK/NEWPAY bank.

11 – The COELSA administrator receives the credit and performs the forced credit at the COELSA destination bank.

12 – The COELSA administrator notifies the push credit to the COELSA PSP.

1.4.3. Unsuccessful path

The credits will be forced, both by LINK/NEWPAY and by COELSA. In the event that the ACK is not received from COELSA for the credit notification from LINK/NEWPAY in the ISO messaging, the sending of the notice will be retried for up to 24h and the operation will be reported at the end of the compensation day in the reconciliation file.

CENTRAL BANK OF THE ARGENTINE REPUBLIC

1.5. COELSA Bank sends funds to a LINK/NEWPAY bank – Forced credit

Agreed process for the case in which a push transfer is initiated from any channel of a bank that operates with COELSA to send funds to a bank that operates with LINK/NEWPAY.

1.5.1. Transactional flow

1.5.2. Successful path

In bold: interaction points between administrators.

0 – The COELSA bank initiates a push transfer (account holder inquiry).

1 – The COELSA administrator performs the active account inquiry (*) destination to the LINK/NEWPAY administrator.

2 – Response from the LINK/NEWPAY administrator (CBU).

3 – Response from the COELSA administrator to the COELSA bank.

4 – The COELSA bank initiates the push transfer (transfer).

5 – The COELSA administrator receives the request and sends a debit request to the COELSA originating bank.

A. The COELSA originating bank performs the balance validation – authorizes debit.

6 – The COELSA originating bank confirms the debit to the COELSA administrator.

7 – The COELSA administrator:

A. Performs and notifies the credit to the LINK/NEWPAY administrator. LINK/NEWPAY responds with an ACK to the COELSA processor.

B. The COELSA administrator responds the operation to the COELSA bank.

8 – The LINK/NEWPAY administrator receives the credit and notifies the credit to the processor LINK/NEWPAY.

9 – The LINK/NEWPAY processor:

A. Performs the forced credit in the LINK/NEWPAY destination bank.

B. Responds to the LINK/NEWPAY administrator.

(*) COELSA must perform the active account inquiry.

1.5.3. Unsuccessful path

The credits will be forced, both by LINK/NEWPAY and by COELSA. In the event that the ACK is not received from COELSA for the credit notification from link/NEWPAY in the ISO messaging, the sending of the notice will be retried for up to 24h and the operation will be reported at the end of the compensation day in the reconciliation file.

1.6. COELSA PSP sends funds to a LINK/NEWPAY PSP – Forced credit

Process for the case in which a push transfer is initiated from any channel of a PSP that operates with COELSA to send funds to a PSP that operates with LINK/NEWPAY.

1.6.1. Transactional flow

1.6.2. Successful path

In bold: interaction points between administrators.

0 – The COELSA PSP initiates a push transfer (CBU and CVU account holder inquiry).

1 – The COELSA administrator resolves the destination CVU account holder inquiry.

2 – The COELSA administrator performs the active account inquiry (*) of the collecting CBU to the processor of the PSP's bank.

3 – Response from the processor of the PSP's bank (CBU).

4 – Response from the COELSA administrator to the COELSA PSP.

5 – The COELSA PSP performs the debit in the CVU.

6 – The COELSA PSP initiates the push transfer (transfer).

7 – The COELSA administrator receives the request and sends a debit request to the COELSA originating bank.

A. The COELSA originating bank performs the balance validation – authorizes debit.

8 – The COELSA originating bank confirms the debit to the COELSA administrator.

9 – The COELSA administrator:

A.
Performs and notifies the credit to the LINK/NEWPAY administrator. LINK/NEWPAY res- ponds with an ACK to the COELSA processor. B. The COELSA administrator responds the operation to the COELSA PSP. 10 – The LINK/NEWPAY administrator receives the credit and notifies the credit to the processor LINK/NEWPAY. 11 – The LINK/NEWPAY processor:
A.
Performs the forced credit in the LINK/NEWPAY destination bank.
B.
Responds to the LINK/NEWPAY administrator.
12 – The LINK/NEWPAY administrator:
A.
Notifies the push credit to the LINK/NEWPAY PSP.

(*) COELSA must perform the active account query.

1.6.3. Unsuccessful path

The credits will be forced, both by LINK/NEWPAY and by COELSA. In the event that the ACK is not received from COELSA for the credit notification from LINK/NEWPAY in the ISO messaging, the sending of the notice will be retried for up to 24h and the operation will be reported at the end of the compensation day in the reconciliation file.

1.7. COELSA PSP sends funds to a LINK/NEWPAY bank – Forced credit

Agreed process for the case in which a push transfer is initiated from any channel of a PSP that operates with COELSA to send funds to a bank that operates with LINK/NEWPAY.

1.7.1. Transactional flow

1.7.2. Successful path

In bold: interaction points between administrators.

0 – The COELSA PSP initiates a push transfer (CBU and CVU account holder query).

1 – The COELSA administrator performs the active account query (*) destined for the LINK/NEWPAY administrator.

2 – Response from the LINK/NEWPAY administrator.

3 – Response from the COELSA administrator to the COELSA PSP.

4 -– The COELSA PSP performs the debit on the CVU.

5 – The COELSA PSP initiates the push transfer (transfer).

6 – The COELSA administrator receives the request and sends a debit request to the COELSA originating bank.

A. The COELSA originating bank performs the balance validation – authorizes debit.

7 – The COELSA originating bank confirms the debit to the COELSA administrator.

8 – The COELSA administrator:

A.
Performs and notifies the credit to the LINK/NEWPAY administrator. LINK/NEWPAY res- ponds with an ACK to the COELSA processor.

B. The COELSA administrator responds the operation to the COELSA PSP.

9 – The LINK/NEWPAY administrator receives the credit and notifies the credit to the LINK/NEWPAY processor.

10 – The LINK/NEWPAY processor:

A. Performs the forced credit in the LINK/NEWPAY destination bank.

B. Responds to the LINK/NEWPAY administrator.

(*) COELSA must perform the active account query.

1.7.3. Unsuccessful path

The credits will be forced, both by LINK/NEWPAY and by COELSA. In the event that the ACK is not received from COELSA for the credit notification from LINK/NEWPAY in the ISO messaging, the sending of the notice will be retried for up to 24h and the operation will be reported at the end of the compensation day in the reconciliation file.

CENTRAL BANK OF THE ARGENTINE REPUBLIC

1.8. COELSA Bank sends funds to a LINK/NEWPAY PSP – Forced credit

Process for the case in which a push transfer is initiated from any channel of a bank that operates with COELSA to send funds to a PSP that operates with LINK/NEWPAY.

1.8.1. Transactional flow

1.8.2. Successful path

In bold: interaction points between administrators.

0 – The COELSA bank initiates a push transfer (CBU and CVU account holder query).

1 – The COELSA administrator performs the active account query for the destination CVU to the LINK/NEWPAY administrator.

2 – Response from the LINK/NEWPAY administrator (CVU).

3 – The COELSA administrator performs the active account query (*) of the collecting CBU to the processor of the PSP bank

4 – Response from the processor of the PSP bank (CBU).

5 – Response from the COELSA administrator to the COELSA bank.

6 – The COELSA bank initiates the push transfer (transfer).

7 – The COELSA administrator receives the request and sends a debit request to the COELSA originating bank.

A. The COELSA originating bank performs the balance validation – authorizes debit.

9 – The COELSA originating bank confirms the debit to the COELSA administrator.

10 – The COELSA administrator:

A. Performs and notifies the credit to the LINK/NEWPAY administrator. LINK/NEWPAY responds with an ACK to the COELSA administrator.

B. The COELSA administrator notifies the operation to the COELSA bank.

11 – The LINK/NEWPAY administrator receives the credit and notifies the credit to the LINK/NEWPAY processor.

12 – The LINK/NEWPAY administrator:

A. Notifies the push credit to the LINK/NEWPAY PSP.

(*) COELSA must perform the active account query

1.8.3. Unsuccessful path

The credits will be forced, both by LINK/NEWPAY and by COELSA. In the event that the ACK is not received from COELSA for the credit notification from LINK/NEWPAY in the ISO messaging, the sending of the notice will be retried for up to 24h and the operation will be reported at the end of the compensation day in the reconciliation file.

CENTRAL BANK
OF THE ARGENTINE REPUBLIC

2. Scenario/transaction analysis pull

2.1. LINK/NEWPAY Bank requests funds from a COELSA bank – Forced credit

2.2. LINK/NEWPAY PSP requests funds from a COELSA PSP – Forced credit

2.3. LINK/NEWPAY PSP requests funds from a COELSA bank – Forced credit

2.4. LINK/NEWPAY Bank requests funds from a COELSA PSP – Forced credit

2.5. COELSA Bank requests funds from a LINK/NEWPAY bank – Forced credit

2.6. COELSA PSP requests funds from a LINK/NEWPAY PSP – Forced credit

2.7. COELSA PSP requests funds from a LINK/NEWPAY bank – Forced credit

2.8. COELSA Bank requests funds from a LINK/NEWPAY PSP – Forced credit

It is clarified that, in all flows, the administrator and processor are always the same entity.

CENTRAL BANK
OF THE ARGENTINE REPUBLIC

2.1.
LINK/NEWPAY Bank requests funds from a COELSA bank – Forced credit

Process for the case in which a pull transfer is initiated from any channel of a bank that operates with LINK/NEWPAY to request funds from a bank that operates with COELSA.

2.1.1. Transactional flow

2.1.2. Successful path

In bold: interaction points between administrators.

0 – The LINK/NEWPAY bank initiates a pull transfer (sending initialization data + JWT).

1 – JWT validation:

A. Operation rejected.

B. Operation approved.

2 – The LINK/NEWPAY administrator performs a destination CBU ownership query to the LINK/NEWPAY processor.

3 – Response from the LINK/NEWPAY processor to the LINK/NEWPAY administrator.

4 – The LINK/NEWPAY administrator performs an origin CBU ownership query to the COELSA administrator.

5 – Response from the COELSA administrator to the LINK/NEWPAY administrator.

6 – The LINK/NEWPAY administrator sends a debit request to the COELSA administrator.

7 – The COELSA administrator receives the debit request from the LINK/NEWPAY administrator:

A. The COELSA administrator sends the debit request to the COELSA origin bank.

B. The COELSA origin bank performs balance validation – authorizes the debit.

C. The COELSA origin bank confirms the debit to the COELSA administrator.

8 – The COELSA administrator confirms the debit to the LINK/NEWPAY administrator. Synchronous response message from point 6.

9 – The LINK/NEWPAY administrator notifies the credit to the LINK/NEWPAY processor.

10 – The LINK/NEWPAY processor notifies the credit in the destination bank and notifies the LINK/NEWPAY administrator.

11 – The LINK/NEWPAY administrator responds the result of the transaction to the LINK/NEWPAY bank.

2.1.3. Unsuccessful path

Possible error situations are detailed only at the interaction points between schemes.

6 - Administrator (LINK/NEWPAY) sends debit request to the COELSA administrator.

The maximum time defined for this step will be agreed between administrators.

Possible situations:

• The LINK/NEWPAY administrator has no response from the debit request API, therefore, they do not know whether COELSA made the fund movement or not.

• A technical reversal request is initiated to COELSA, which reverses the funds to the origin bank, and notifies the bank of the reversal made.

In case of not receiving a response from COELSA regarding the reversal, a retry scheme is established (number and frequency of retries to be defined between administrators) for the reversal notice by LINK/NEWPAY.

Finally, in case the operation cannot be reversed, and once the retries are concluded, the operation will be reversed at the end of the compensation day in the reconciliation file.

CENTRAL BANK
OF THE ARGENTINE REPUBLIC

2.2. LINK/NEWPAY PSP requests funds from a COELSA PSP –Forced credit

Process for the case in which a pull transfer is initiated from any channel of a PSP that operates with LINK/NEWPAY to request funds from a PSP that operates with COELSA.

2.2.1. Transactional flow

2.2.2. Successful path

In bold: interaction points between administrators.

0 – The LINK/NEWPAY PSP initiates a pull transfer (sending initialization data + JWT).

1 – JWT validation:

A. Operation rejected.

B. Operation approved.

2 – The LINK/NEWPAY administrator performs a destination CVU ownership query to the LINK/NEWPAY processor.

3 – Response from the LINK/NEWPAY processor to the LINK/NEWPAY administrator.

4 – The LINK/NEWPAY administrator performs an origin CVU ownership query to COEL-SA.

5 – Response from COELSA to the LINK/NEWPAY administrator.

6 – Administrator LINK/NEWPAY performs an ownership inquiry of the destination CBU to the LINK/NEWPAY processor.

7 – Response from the processor to the LINK/NEWPAY administrator.

8 – Administrator LINK/NEWPAY sends a debit request to the COELSA administrator.

9 – The COELSA administrator receives the debit request from the LINK/NEWPAY administrator:

A. The COELSA administrator sends the debit request to the PSP.

B. The PSP performs the balance validation – authorizes debit.

C. The PSP confirms the debit to the COELSA administrator.

D. The COELSA administrator sends the debit request to the COELSA originating bank.

E. The COELSA originating bank performs the balance validation – authorizes debit.

F. The COELSA bank confirms the debit to the COELSA administrator.

10 – The COELSA administrator confirms the debit to the LINK/NEWPAY administrator. Synchronous response message from point 8.

11 – The LINK/NEWPAY administrator notifies the credit to the LINK/NEWPAY processor.

12 – The LINK/NEWPAY processor notifies the credit at the destination bank and notifies the LINK/NEWPAY administrator.

13 – The LINK/NEWPAY administrator responds the result of the transaction to the LINK/NEWPAY PSP.

14 – The LINK/NEWPAY PSP credits to the CVU.

2.2.3. Unsuccessful path

Possible error situations are detailed only at the interaction points between schemes.

8 – The administrator (LINK/NEWPAY) sends a debit request to the COELSA administrator.

The maximum time defined for this step will be agreed between administrators.

Possible situations:

• The LINK/NEWPAY administrator has no response from the debit request API, therefore it does not know whether COELSA made the fund movement or not.

• A technical reversal request is initiated to COELSA, which reverses the funds to the sponsor bank/PSP, and notifies the PSP of the reversal made.

In case of not receiving a response from COELSA regarding the reversal, a retry scheme is established (to be defined between administrators as to the number and frequency of retries) for the reversal notice by LINK/NEWPAY.

Finally, if the operation cannot be reversed, and once the retries are concluded, the operation will be reversed at the end of the compensation day in the reconciliation file.

BANCO CENTRAL
DE LA REPÚBLICA ARGENTINA

2.3. PSP of LINK/NEWPAY requests funds from a COELSA bank – Forced credit

Process for the case in which a pull transfer is initiated from a channel of a PSP that operates with LINK/NEWPAY to request funds from a bank that operates with COELSA.

2.3.1. Transactional flow

2.3.2. Successful path

In bold: interaction points between administrators.

0 – The LINK/NEWPAY PSP initiates a pull transfer (sending initialization data + JWT).

1 – JWT validation:

A. Operation rejection.

B. Operation approved.

2 – The LINK/NEWPAY administrator performs an ownership inquiry of the destination CVU to the LINK/NEWPAY processor.

3 – Response from the LINK/NEWPAY processor to the LINK/NEWPAY administrator.

4 – The LINK/NEWPAY administrator performs an ownership inquiry of the originating CBU to COEL-SA.

5 – Response from COELSA to the LINK/NEWPAY administrator.

6 – Administrator LINK/NEWPAY performs an ownership inquiry of the destination CBU to the LINK/NEWPAY processor.

7 – Response from the processor to the LINK/NEWPAY administrator.
8 – Administrator LINK/NEWPAY sends a debit request to the COELSA administrator.
9 – The COELSA administrator receives the debit request from the LINK/NEWPAY administrator:
A.
The COELSA administrator sends the debit request to the COELSA originating bank.
B.
The COELSA originating bank performs the balance validation – authorizes debit.
C.
The COELSA bank confirms the debit to the COELSA administrator.
10 – The COELSA administrator confirms the debit to the LINK/NEWPAY administrator. Message of synchronous response from point 8. 11 – The LINK/NEWPAY administrator notifies the credit to the LINK/NEWPAY processor. 12 – The LINK/NEWPAY processor notifies the credit at the destination bank and notifies the administrator LINK/NEWPAY. 13 – The LINK/NEWPAY administrator responds the result of the transaction to the PSP of LINK/NEWPAY. 14 – The LINK/NEWPAY PSP credits to the CVU.

2.3.3. Unsuccessful path

Possible error situations are detailed only at the interaction points between schemes.

8 – The administrator (LINK/NEWPAY) sends a debit request to the COELSA administrator.

The maximum time defined for this step will be agreed upon between administrators.

Possible situations:

• The LINK/NEWPAY administrator has no response from the debit request API, therefore it does not know whether COELSA executed the fund movement or not.

• A technical reversal request is initiated to COELSA, which reverses the funds to the sponsor bank/PSP, and notifies the PSP of the reversal performed.

In the event of not receiving a response from COELSA regarding the reversal, a retry scheme is established (to be defined between administrators as to the number and frequency of retries) for the reversal notice by LINK/NEWPAY.

Finally, if the operation cannot be reversed, and once the retries are concluded, the operation will be reversed at the end of the compensation day in the reconciliation file.

BANCO CENTRAL
DE LA REPÚBLICA ARGENTINA

2.4. LINK/NEWPAY Bank requests funds from a COELSA PSP – Forced credit

Process for the case in which a pull transfer is initiated from any channel of a bank that operates with LINK/NEWPAY to request funds from a PSP that operates with COELSA.

2.4.1. Transactional flow

2.4.2. Successful path

In bold: interaction points between administrators.

0 – The LINK/NEWPAY bank initiates a pull transfer (sending initialization data + JWT).

1 – JWT validation:

A. Operation rejection.

B. Operation approved.

2 – The LINK/NEWPAY administrator performs a query of the ownership of the source CVU to COEL-SA.

3 – COELSA's response to the LINK/NEWPAY administrator.

4 – LINK/NEWPAY administrator performs a query of the ownership of the destination CBU to the LINK/NEWPAY processor.

5 – Processor's response to the LINK/NEWPAY administrator.

6 – LINK/NEWPAY administrator sends a debit request to the COELSA administrator.

7 – The COELSA administrator receives a debit request from the LINK/NEWPAY administrator:

A. The COELSA processor sends the debit request to the PSP.

B. The PSP performs balance validation – authorizes debit.

C. The PSP confirms the debit to the COELSA administrator.

D. The COELSA administrator sends a debit request to the COELSA source bank.

E. The COELSA source bank performs balance validation – authorizes debit.

F. The COELSA bank confirms the debit to the COELSA administrator.

8 – The COELSA administrator confirms the debit to the LINK/NEWPAY administrator. Synchronous response message from point 6.

9 – The LINK/NEWPAY administrator notifies the credit to the LINK/NEWPAY processor.

10 – The LINK/NEWPAY processor notifies the credit in the destination bank and notifies the LINK/NEWPAY administrator.

11 – The LINK/NEWPAY administrator responds the result of the transaction to the LINK/NEWPAY bank.

2.4.3. Unsuccessful path

Possible error situations are detailed only at the interaction points between schemes.

8 – The administrator (LINK/NEWPAY) sends a debit request to the COELSA administrator.

The maximum time defined for this step will be agreed upon between administrators.

Possible situations:

• The LINK/NEWPAY administrator has no response from the debit request API, therefore it does not know whether COELSA executed the fund movement or not.

• A technical reversal request is initiated to COELSA, which reverses the funds to the sponsor bank/PSP, and notifies the PSP of the reversal performed.

In the event of not receiving a response from COELSA regarding the reversal, a retry scheme is established (to be defined between administrators as to the number and frequency of retries) for the reversal notice by LINK/NEWPAY.

Finally, if the operation cannot be reversed, and once the retries are concluded, the operation will be reversed at the end of the compensation day in the reconciliation file.

2.5.
COELSA Bank requests funds from a LINK/NEWPAY bank – Forced credit

Process for the case in which a pull transfer is initiated from any channel of a bank that operates with COELSA to request funds from a bank that operates with LINK/NEWPAY.

2.5.1. Transactional flow

2.5.2. Successful path

In bold: interaction points between administrators.

0 – The COELSA bank initiates a pull transfer (sending initialization data + JWT).

1 – JWT validation:

A. Operation rejection.

B. Operation approved.

2 – The COELSA administrator resolves the query of the ownership of the destination CBU.

3 – The COELSA administrator resolves the query of the ownership of the source CBU.

4 – The COELSA administrator sends a debit request to the LINK/NEWPAY administrator.

5 – The LINK/NEWPAY administrator receives a debit request from the COELSA administrator:

A. Forwards the debit request to the LINK/NEWPAY processor.

B.
The LINK/NEWPAY processor sends the debit request to the originating bank of LINK/NEWPAY.

C. The originating bank of LINK/NEWPAY performs balance validation – authorizes the debit.

D. The originating bank of LINK/NEWPAY confirms the debit to the LINK/NEWPAY processor.

E. The LINK/NEWPAY processor informs the LINK/NEWPAY administrator of the debit.

6 – The LINK/NEWPAY administrator confirms the debit to the COELSA administrator. Synchronous response message from point 6.

7 – The COELSA administrator notifies the destination bank of COELSA of the credit.

8 – The COELSA administrator responds the result of the transaction to the COELSA bank.

2.5.3. Unsuccessful path

Possible error situations are detailed only at the interaction points between schemes.

6 – Administrator (COELSA) sends debit request to the LINK/NEWPAY administrator.

The maximum time defined for this step will be agreed upon between administrators.

Possible situations:

• The COELSA administrator has no response from the debit request API, therefore, it does not know whether LINK/NEWPAY made the fund movement or not.

• A technical reversal request is initiated to LINK/NEWPAY, which reverses the funds to the originating bank, and notifies the bank of the reversal performed.

In case of not receiving a response from LINK/NEWPAY regarding the reversal, a retry scheme is established (number and frequency of retries to be defined between administrators) for the reversal notice by COELSA.

Finally, in case the operation cannot be reversed, and once the retries are concluded, the operation will be reversed at the end of the compensation day in the reconciliation file.

2.6.
COELSA PSP requests funds from a LINK/NEWPAY PSP – Forced credit

Process for the case in which a pull transfer is initiated from any channel of a PSP that operates with COELSA to request funds from a PSP that operates with LINK/NEWPAY.

2.6.1. Transactional flow

2.6.2. Successful path

In bold: interaction points between administrators.

0 – The COELSA PSP initiates a pull transfer (sending initialization data + JWT).

1 – JWT validation:

A. Operation rejection.

B. Operation approved.

2 – The COELSA administrator resolves the ownership query of the destination CVU.

3 – The COELSA administrator resolves the ownership query of the originating CVU.

4 – COELSA administrator resolves the ownership query of the destination CBU.

5 – COELSA administrator sends debit request to the LINK/NEWPAY administrator.

6 – The LINK/NEWPAY administrator receives the debit request from the COELSA administrator:

A. Forwards the debit request to the LINK/NEWPAY processor.

B.
The LINK/NEWPAY processor sends the debit request to the PSP.
C.
The PSP performs balance validation – authorizes debit.
D.
The PSP confirms the debit to the LINK/NEWPAY processor.
E.
The LINK/NEWPAY processor sends the debit request to the originating bank of LINK/NEWPAY.
F.
The originating bank of LINK/NEWPAY performs balance validation – authorizes debit.
G.
The LINK/NEWPAY bank confirms the debit to the LINK/NEWPAY processor.
H.
The LINK/NEWPAY processor informs the LINK/NEWPAY administrator of the debit.

7 – The LINK/NEWPAY administrator confirms the debit to the COELSA administrator. Synchronous response message from point 8.

8 – The COELSA administrator notifies the destination bank of COELSA of the credit.

9 – The COELSA administrator responds the result of the transaction to the COELSA PSP.

10 – The COELSA PSP credits to the CVU.

2.6.3. Unsuccessful path

Possible error situations are detailed only at the interaction points between schemes.

8 – The administrator (COELSA) sends debit request to the LINK/NEWPAY administrator.

The maximum time defined for this step will be agreed upon between administrators. Possible situations:

• The COELSA administrator has no response from the debit request API, therefore, it does not know whether LINK/NEWPAY made the fund movement or not.

• A technical reversal request is initiated to LINK/NEWPAY, which reverses the funds to the sponsor bank/PSP, and notifies the PSP of the reversal performed.

In the event of not receiving a response from LINK/NEWPAY regarding the reversal, a retry scheme is established (to be defined between administrators as to the number and frequency of retries) for the reversal notice by COELSA.

Finally, if the operation cannot be reversed, and once the retries are completed, the operation will be reversed at the end of the compensation day in the reconciliation file.

2.7. COELSA's PSP requests funds from a LINK/NEWPAY bank – Forced credit

Process for the case in which a pull transfer is initiated from a channel of a PSP that operates with COELSA to request funds from a bank that operates with LINK/NEWPAY.

2.7.1. Transactional flow

2.7.2. Successful path

In bold: interaction points between administrators.

0 – COELSA's PSP initiates a pull transfer (sending initialization data + JWT).

1 – JWT validation: COELSA

A. Operation rejection.

B. Operation approved.

2 – The COELSA administrator resolves the ownership query of the destination CVU.

3 – The COELSA administrator resolves the ownership query of the source CBU.

4 – COELSA administrator resolves the ownership query of the destination CBU.

5 – COELSA administrator sends debit request to the LINK/NEWPAY administrator.

6 – The LINK/NEWPAY administrator receives the debit request from the COELSA administrator:

A.
Forwards the debit request to the LINK/NEWPAY processor.
B.
The LINK/NEWPAY processor sends the debit request to the source bank of LINK/NEWPAY.
C.
The source bank of LINK/NEWPAY performs the balance validation – authorizes debit.
D.
The LINK/NEWPAY bank confirms the debit to the LINK/NEWPAY processor.
E.
The LINK/NEWPAY processor informs the debit to the LINK/NEWPAY administrator.

7 – The LINK/NEWPAY administrator confirms the debit to the COELSA administrator. Synchronous response message from point 8.

8 – The COELSA administrator notifies the credit to the destination bank of COELSA.

9 – The COELSA administrator responds the result of the transaction to COELSA's PSP.

10 – COELSA's PSP credits in the CVU.

2.7.3. Unsuccessful path

Possible error situations are detailed only at the interaction points between schemes.

8 – The administrator (COELSA) sends a debit request to the LINK/NEWPAY administrator.

The maximum time defined for this step will be agreed between administrators. Possible situations:

• The COELSA administrator has no response from the debit request API, therefore, it does not know whether LINK/NEWPAY performed the fund movement or not.

• A technical reversal request is initiated to LINK/NEWPAY, which reverses the funds to the sponsor bank/PSP, and notifies the PSP of the reversal performed.

In the event of not receiving a response from LINK/NEWPAY regarding the reversal, a retry scheme is established (to be defined between administrators as to the number and frequency of retries) for the reversal notice by COELSA.

Finally, if the operation cannot be reversed, and once the retries are completed, the operation will be reversed at the end of the compensation day in the reconciliation file.

CENTRAL BANK
OF THE ARGENTINE REPUBLIC

2.8. COELSA's Bank requests funds from a LINK/NEWPAY PSP –Forced credit

Process for the case in which a pull transfer is initiated from a channel of a bank that operates with COELSA to request funds from a PSP that operates with LINK/NEWPAY.

2.8.1. Transactional flow

2.8.2. Successful path

In bold: interaction points between administrators.

0 – COELSA's bank initiates a pull transfer (sending initialization data + JWT).

1 – JWT validation:

A. Operation rejection.

B. Operation approved.

2 – The COELSA administrator resolves the ownership query of the source CVU.

3 – COELSA administrator resolves the ownership query of the destination CBU.

4 – COELSA administrator sends debit request to the LINK/NEWPAY administrator.

5 – The LINK/NEWPAY administrator receives the debit request from the COELSA administrator:

A.
Forwards the debit request to the LINK/NEWPAY processor.
B.
The LINK/NEWPAY processor sends the debit request to the PSP.
C.
The PSP performs the balance validation – authorizes debit.
D.
The PSP confirms the debit to the LINK/NEWPAY processor.
E.
The LINK/NEWPAY processor sends the debit request to the originating bank of LINK/NEWPAY.
F.
The originating bank of LINK/NEWPAY performs the balance validation – authorizes debit.
G.
The bank of LINK/NEWPAY confirms the debit to the LINK/NEWPAY processor.
H.
The LINK/NEWPAY processor informs the debit to the LINK/NEWPAY administrator.

6 – The LINK/NEWPAY administrator confirms the debit to the COELSA administrator. Synchronous response message from point 6.

7 – The COELSA administrator notifies the credit to the destination bank of COELSA.

8 – The COELSA administrator responds the result of the transaction to the bank of COELSA.

2.8.3. Unsuccessful path

Possible error situations are detailed only at the interaction points between schemes.

8 – The administrator (COELSA) sends a debit request to the LINK/NEWPAY administrator.

The maximum time defined for this step will be agreed between administrators.

Possible situations:

• The COELSA administrator has no response from the debit request API, therefore, it does not know whether LINK/NEWPAY made the fund movement or not.

• A technical reversal request is initiated to LINK/NEWPAY, which reverses the funds to the sponsor bank/PSP, and notifies the PSP of the reversal made.

In case of not receiving a response from LINK/NEWPAY regarding the reversal, a retry scheme is established (to be defined between administrators as to the number and frequency of retries) for the reversal notice by COELSA.

Finally, if the operation cannot be reversed, and once the retries are concluded, the operation will be reversed at the end of the compensation day in the reconciliation file.