Circular SINAP 1-116: Payment Service Providers. National Payments System - Transfers. National Payments System - Mobile Payments Platform (PPM). Adjustments — BCRA — AR

“2020 - YEAR OF GENERAL MANUEL BELGRANO”
COMMUNICATION “A” 7153 30/10/2020
TO FINANCIAL ENTITIES,
TO ELECTRONIC CLEARING HOUSES,
TO AUTOMATED TELLER MACHINE NETWORK ADMINISTRATOR COMPANIES, TO PAYMENT SERVICE PROVIDERS, TO FINANCIAL MARKET INFRASTRUCTURES, TO PAYMENT SERVICE PROVIDERS THAT OFFER PAYMENT ACCOUNTS:
Ref.: Circular
SINAP 1 - 116
Payment Service Providers. National
Payments System – Transfers.
National Payments System – Mobile
Payments Platform (PPM). Adjustments
.
____________________________________________________________ We address you to inform you that this Institution adopted the following resolution, regarding Payment Service Providers and the National Payments System for the regulation of Transfers and Mobile Payment Platform, which incorporates, with the expansions expressly contemplated, the current provisions for Immediate Electronic Payment (PEI) and which in its pertinent part establishes:

“1. Replace, with effect from December 7, 2020, the rules on “National Payments System – Transfers” with those attached in Annex I to this communication.
2. Approve the rules on “National Payments System – Transfers – Supplementary Rules” attached in Annex II to this communication, establishing December 7, 2020 as the implementation date for phase 1 and November 29, 2021 as the deadline for the implementation of the remaining phases necessary to achieve full validity of these rules.
3. Provide that until such time as the immediate transfer payment schemes are adjusted to points 2.9. and 6.4. of the rules on “National Payments System – Transfers – Supplementary Rules”, points 2.3.1.2. item iv), 2.2.2.8. and 2.2.2.11. of the rules on “National Payments System – Transfers” in force at the date of this communication shall apply.
4. Replace, with effect from December 7, 2020, the rules on “Payment Service Providers” that offer payment accounts” with those attached in Annex III to this communication.
5. Provide, with effect from December 7, 2020, the incorporation of Section 1. of the rules on “National Payments System. Mobile Payments Platform (PPM)” as Section 4. of the rules on “National Payments System – Transfers” according to the text transcribed below, and the replacement of the remaining sections on “National Payments System. Mobile Payments Platform (PPM)” with those of “National Payments System – Transfers – Supplementary Rules”:

-2-
“Section 4. Access cards to checking accounts.
Financial entities must provide their customers with an access card to their checking accounts, which allows –among other services– to make immediate fund transfers, including the ‘Payments with transfer’ according to Section 3 of the rules on “National Payments System – Transfers – Supplementary Rules”.”
6. Authorize as administrators of electronic fund transfer payment schemes Compensadora Electrónica S.A., Interbanking S.A., Prisma Medios de Pago S.A. and Red Link S.A.”

Likewise, we inform you that we will subsequently send you the sheets that, in replacement of those previously provided, will correspond to replace in the rules on “National Payments System – Transfers”, “National Payments System – Transfers – Supplementary Rules” and “Payment Service Providers”.

We salute you attentively.
CENTRAL BANK OF THE ARGENTINE REPUBLIC
Pablo García Arabehety Luis A. D’Orio
Manager of Payment Systems Manager of Payment Systems and Current Accounts

ANNEX

-Index
Section 1. Batch Transfers.
1.1. Participation.
1.2. Product Description.
1.3. Operational Instructions.
1.4. Participant Responsibilities.
1.5. Controls to be performed.
1.6. Transactions.
1.7. Record Design.
Section 2. Immediate Transfers.
2.1. Introduction and objective.
2.2. Characteristics.
2.3. Participant Responsibilities.
Section 3. Electronic fund transfers: unique references, information to customers and
description of operations.
3.1. Unique references.
3.2. Customer information and description of operations.
Section 4. Access cards to checking accounts.
B.C.R.A. National Payments System – Transfers
Annex I to
Comm. “A”
7153

Section 1: Batch Transfers.
The present section aims to define the operational instructions for batch transfers.
These operational instructions define the manner in which system participants will operate, the circuits for sending, clearing and distributing information and transactions, the controls to be performed by participants, their responsibilities and the characteristics of the information to be exchanged electronically. The definitions of Section 1. of the rules “National Payments System – Transfers – Supplementary Rules” apply to these rules.

1.1. Participation.
1.1.1. Form of participation.
The form of participation of entities in the electronic clearing system for transfers is through Electronic Clearing Houses (CEC).
This participation may be, at the choice of the entities, direct as a full member of a clearing house, or indirect through the designation of another member entity as its representative. In the settlement phase in accounts opened at the Central Bank of the Argentine Republic (BCRA), only the full members of each clearing house will intervene. The representative entity must identify in the exchange process the documents it presents on behalf of the represented entity. It will be the responsibility of the entities to operate according to the standards and formats defined by these operational instructions for the purpose of the electronic exchange of transfer information.

1.1.2. Specific Participants.
In addition to the financial entities declared as participants in Section 1. of the rules “National Payments System – Transfers – Supplementary Rules”, the specific form of participation in batch transfers for the following cases is defined below:

The Transmission Center.
The CECs.
The BCRA.

Transmission Center:
It comprises the telecommunications elements through which the various entities effect the emission or reception of electronic information to and from the CEC.
Entities may install a Transmission Center in one or more branches, at their headquarters and/or in one or more external centers belonging to a third party that provides them with this service through an agreement. Each entity may use as many Transmission Centers as necessary to cover its entire branch network. In the CEC that provides them with service, each of these branches will have an assigned Transmission Center, both for the emission of information to the CEC and for the reception of information. The Transmission Centers will have no effect on clearing, but will act only as points of sending and receiving files. In the event that the entity uses more than one Transmission Center to receive information from the CEC, the receipt of the net positions resulting from the clearing from the latter may be effected in a single predetermined Transmission Center.

Electronic Clearing Houses (CEC):
They are defined in Section 1. of the rules “National Payments System – Transfers – Supplementary Rules”. They work in free competition providing the clearing services defined in these instructions. They communicate with each other to exchange cross transactions, which enables entities to communicate only with one CEC, and this one to take charge of the transactions of all entities, regardless of whether they are clients of it or not. The specific tasks they will perform, regarding batch transfers, are the following:

Consolidation of the files received from the various originating entities and classification of the information by receiving entity, generating and sending output files with the transaction details for them (submitted session).
Consolidation of the files sent by the receiving entities and classification of the information by originating entity, generating and sending output files with the transaction details for them (rejected session).
Exchange of transactions with the remaining CECs.
Calculation of bilateral positions of each entity and sending of these to each of them.
Settlement of balances in current accounts opened at the BCRA.
Sending of statistical and control information to the BCRA.
Administration of interbank commissions associated with the process.
The relationship between participants is described in the following table:

1.1.3. Entities covered by the service.
These are the financial entities that have current and/or savings accounts enabled or other entities authorized by the BCRA and, in addition, have a current account opened at the BCRA, who must provide the “Transfers” service according to the forms of intervention and service provision established below.

To perform the electronic clearing of transfers, entities must have the necessary procedures to be homologated in the CECs as receivers and originators.

1.2. Product Description.
The transfers contemplated in this clearing system must meet the following characteristics:

That it must obligatorily contain information relative to:
− The originating client (Name / Business Name and the CUIT, CUIL, CDI or DNI number of the orderer).
− The account to be credited based on the Uniform Banking Key (CBU) and the CUIT, CUIL or CDI number of the beneficiary.
− The movement of funds (amount and currency of the transfer).
− The identification of the movement of funds (originating entity, unique identification).
That they be in pesos or in foreign currency authorized by the BCRA.
Batch transfers may be issued for the following concepts:
− Salary payments.
− Pension payments.
− Family allowances.
− Seizures on wages by judicial order.
− Payments to suppliers.
− Between clients or clients and third parties.

1.2.1. Product Description Salary Payments, Pension Payments, Family Allowances and Seizures on wages by judicial order.
Accounts on which the service applies.
This product is created to transfer money between existing accounts of different entities in the system.
Both the payer (originator) and the beneficiary (receiver) must have an account open at a financial entity.
These are deposit accounts in savings and similar, and in bank current accounts, subject to the current conditions and attributes according to the regulations issued by the BCRA.

Constitution of coverage account.
It consists of the opening of an operational current account for the CECs to settle only these transfers.
In this account, originating entities will transmit via the Electronic Payment Medium System (M.E.P.), to their respective CEC, the total amount of the presentation of said transfers. Received in the CEC the presentation of the movements, and the funds credited in the coverage account, the CEC will control that the deposit covers the total of the presentation. The lack of coverage of the CEC's operational account in the M.E.P., through the transfer of the total amounts of the product in question, will cause the CEC not to enter the presentation/s in the clearing and settlement process of that day, of the entity/es that have not met such requirement.

24-hour clearing period.
These transfers will be carried out in 24 hours; this means that the originating entity of the movements transmits the information and transfers the funds through the CEC to the receiving entity where the beneficiaries' accounts are located, having these funds available at the beginning of the next day. It will be at the free agreement of the parties, client and originating entity, the moment when the first must deliver to the second the information and funds corresponding to said transfers, so that the originating entity can make its presentation in time and form to its CEC.

Day D: the originating entities send the transfers through the CEC to the receiving entities where the beneficiaries' accounts are located.
Day D: clearing is performed in the CECs, settlement in the BCRA and crediting in the accounts of the receiving entities.
Day D+1: at the beginning of the day, the beneficiary has the funds available in their account.
Day D+1: the receiving entity sends to the originating entity, the returns of transfers that it observed in the processes of day D, as new transfers that are cleared and settled that day in the same and only session.

1.2.2. Product Description Payments to suppliers and between clients or clients and third parties and Payments by judicial order (retail).
1.2.2.1. Accounts on which the service applies.
These retail transfers are created to transfer money between different financial entities participating in the system.
For both Payments to suppliers and Transfers between clients or clients and third parties, the payer (originating client) and the beneficiary (receiving client) must have a bank account at one of the entities. These are deposit accounts in savings and similar, and in bank current accounts, subject to the current conditions and attributes according to the regulations issued by the BCRA.

1.2.2.2. Clearing period.
i) Transfers denominated in pesos.
The clearing scheme for these transfers will be carried out in 24 hours; this means that the originating entity transmits the information through the CEC to the receiving entity where the clients' accounts are located, having these their funds available at the beginning of the next day.

Day D: the originating entities send the transfers through the CEC to the receiving entities where the clients' accounts are located.
Day D: clearing is performed in the CECs, settlement in the BCRA and crediting in the accounts of the receiving entities.
Day D+1: at the beginning of the day, the client has the funds available in their account.
Day D+1: the receiving entity sends to the originating entity, the returns of transfers that it observed in the processes of day D, as new transfers that are cleared and settled that day in the same and only session.

ii) Transfers denominated in foreign currency.
The clearing scheme for these transfers will be carried out in 48 hours; this means that the originating entity transmits the information through the CEC to the receiving entity where the clients' accounts are located. The next day, the rejections of retail transfers observed by the receiving entity will be processed, the net balances will be cleared and settled and the funds will be credited in the receiving accounts. At the beginning of the next day, the client of the receiving entity has the funds available.

Day D: the originating entities send the transfers through the CEC to the receiving entities where the clients' accounts are located.
Day D+1: rejections of retail transfers from the receiving entities are received, clearing is performed in the CECs, settlement of net balances in the BCRA and crediting of funds in the accounts of the receiving entities.
Day D+2: at the beginning of the day, the client of the receiving entity has the funds available.
It is clarified that it will be at the free agreement of the parties, client and originating entity, the moment when the first should deliver to the second the information and funds corresponding to said transfers, so that the originating entity can make its presentation in time and form to its clearing house as established in the present regulation.

1.2.2.3. Integration and settlement of guarantees.
For the Retail Transfers product, what is stipulated by the BCRA in the current regulation applies.

1.2.3. Scope of application.
By this system, Transfers for Salary Payments, Pension Payments, Family Allowances, Seizures on wages by judicial order. and Retail Transfers (Payments to suppliers and between clients or clients and third parties), denominated in pesos, in a period of 24 hours, regardless of their origin and destination, within the national territory, may be electronically cleared. Likewise, Transfers for Payments to suppliers and between clients or clients and third parties, denominated in foreign currency, in a period of 48 hours, regardless of their origin and destination, within the national territory, may be electronically cleared. If the originating and receiving entities operate in different CECs, it will be the responsibility of the latter to exchange transactions to ensure complete system interconnection.

If limitations are generated when defining the scope of the product, these must be of a general nature, avoiding partial implementations that affect the open nature of the system.

1.2.4. Prices to customers: batch transfers will be covered by the price scheme to customers detailed in Sections 5. and 6. of the rules “National Payments System – Transfers – Supplementary Rules”.

1.3. Operational Instructions.
This point contains the operational instructions corresponding to transfers, which will govern the mechanisms of presentation, clearing, communication sessions and other relevant aspects to consider.

1.3.1. Transfer request and clearing at the CEC.
The transfer request by the originating client may be made at the originating entities through the procedures they establish for the capture of the same. These procedures must guarantee the correct authorization of the transfer by the client, regardless of the channel through which it is ordered. The entities will transmit to a CEC files containing the information corresponding to the transfers that each entity presents for its clearing.

1.3.1.1. Salary Payments, Pension Payments, Family Allowances and Seizures on wages by judicial order.
A single session, of submitted, will operate daily.
The transactions to be presented electronically to the CEC are the following:
− Transfer orders.
− Returns of transfers.

1.3.1.2. Retail transfers: Payments to suppliers and between clients or clients and third parties.
i) In pesos.
A single session, of submitted, will operate daily.
The transactions to be presented electronically to the CEC are the following:
− Transfer orders.
− Returns of transfers.

ii) In foreign currency.
Daily, two sessions will operate in which the CEC will receive the files from the entities:
− The submitted session.
− The rejected session.

1.3.1.3. Deadlines and schedules.
For each session (submitted and rejected), the deadline schedules for the presentation of information defined by each CEC for communications between them and their respective adhering entities will apply. This means that entities may transmit files to a CEC throughout the day, from the start of operations time defined by each CEC until the deadline. Entities that are late in sending the information in the submitted session, without having been able to communicate with the CEC within the deadline, must wait until the next business day to transmit the information to be cleared.

1.3.2. Reception and validation of information from the CEC.
The CEC will execute the electronic processing of the information related to transfers, whether received in the submitted session or in the rejected session, from the deadline corresponding to each of them. The CEC will perform validations on the received files, returning them in case of error. The reasons for return will be:

Impossibility of reading the file.
Error in the file structure.
Lack of match in control totals.
Error in the codes of originating and receiving entities.
Originating entity not adhered to the CEC.
Duplicate file.
CUIT, CUIL or CDI of the beneficiary does not match.
The transactions covered by this control will only be:
Presentation of transfers between clients or third parties in pesos and in US dollars.
Presentation of payments to suppliers transfers in pesos and in US dollars.
If the files pass all validations performed by the CEC, it will send an electronic acceptance response, with which it assumes, among others, the responsibility for the correct treatment of the received information. If they do not pass the validations, the CEC reserves the right to request the retransmission of the file in total or in part.

1.3.3. Clearing between CECs.
When the origin and destination entities are adhered to different CECs, an interconnection procedure between them must be applied.
The procedure to be followed in each session will be the following:

The CEC receiving information from the originator entity will, in the first instance, calculate the bilateral clearing movements between itself and all its destination entities.
Secondly, it will retransmit to the other CEC(s) the detailed information of the entities affiliated with it.
The CEC of the destination entities will calculate the bilateral clearing movements between its affiliated entities and the originator, and will forward the transaction details to each destination entity.
Each CEC will communicate the resulting bilateral movements from the clearing to its respective entities.
The CECs will calculate their final position with respect to other CECs. The debtor CEC will pay the creditor CEC to distribute the balance among its members at the BCRA.

The structure, content, and format of the files to be exchanged electronically between the CECs must comply with the specifications and standards defined in points 1.6. "Transactions" and 1.7. "Record Design".

To ensure that there are no delays in sending the information resulting from the clearing to the entities and the BCRA, cutoff times for information transmissions between CECs will be defined. With this information, each CEC can, based on its own times and volumes, define cutoff times with its entities.

The following chart presents the clearing scheme between CECs:

1.3.4. Sending to the entities.
1.3.4.1. Communication of movements.
After the clearing process, all entities will receive from the CEC files containing:

The detail of the cleared movements.
The bilateral balances resulting from the clearing.

In the event that the entity uses more than one Transmission Center to receive information from the CEC, the receipt of the net positions resulting from the clearing from the latter can be carried out in a single predetermined Transmission Center.

This information will be received separately by currency type (pesos or foreign currency authorized by the BCRA) and by product.

1.3.4.2. Processing of received information.

The entities will receive from the CECs the files resulting from the clearing within the reception hours defined by each CEC.
The entities must perform validations on the received files and return them in case any error is detected. The possible reasons for return are:

Impossibility of reading the file.
Error in the file structure.
Lack of match in control totals.
Error in the destination entity code of the information.
Duplicate file.

If the files pass all validations performed by the entity that received the information, it will send an acceptance response assuming responsibility for the received information.
If the validations are not passed, the entities reserve the right to request the retransmission of the file in whole or in part.

1.3.5. Other operational aspects.
1.3.5.1. Business days for clearing.
All days defined by the BCRA as business days will be considered business days for clearing.

1.3.5.2. Non-working days.
Non-working days in a specific location may be subject to no clearing in that location, subject to the definition of the receiving entity.
The operational instructions to be followed on non-working days are as follows:

The CEC will transmit to the receiving entity's Transmission Center the corresponding transactions. This entity will have the option to return the movements received against a location, indicating as the reason for return "non-working day".
In the event that the receiving entity returns the movements received with the reason "non-working day", the originating entity will proceed to present said movements in the next day's clearing.

1.3.5.3. Exception procedure for communication failure.
In the event of a communication failure between the Transmission Centers and the CEC, an alternative information exchange procedure must be planned.
However, if the communication problem has not extended to all entities, those affected will have the option to resort to a Transmission Center of another entity to manage the transmission of information to the CEC.

1.3.6. Transactions to be processed.

1.3.6.1. Transfer orders.
Transfers presented for Salary Payments, Pension Payments, Family Allowances, Seizures of wages by judicial order, and Retail Transfers (Payments to suppliers and between clients or clients and third parties), denominated in pesos, will have a clearing period of 24 hours. Retail transfers presented (Payments to suppliers and between clients or clients and third parties), denominated in foreign currency, will have a clearing period of 48 hours.

i) Presentation.
The originating entities, by order of their clients or third parties, will transmit to a chamber, in the presentation session, the transfer orders to the accounts of the clients of the receiving entities. The information will be transmitted in files whose structure, content, and format are detailed in points 1.6. "Transactions" and 1.7. "Record Design".

ii) CEC Processing.
The CECs will receive and clear the transfers to then inform the receiving entities of the movements resulting from the clearing, according to the schedules defined by them.

iii) Reception by the receiving entity.
Once the information resulting from the clearing is received and its validity is assured, the receiving entities will execute the following processes:

Performing electronic controls on the existence of the account to which the funds will be moved.
Preparation of returns and/or rejections, for all those transfers that could not be executed for any of the established reasons (point 1.3.6.2.).
Posting the transfer to its client's account.

1.3.6.2. Returns or Rejections.
These are the transfers that the receiving entity re-sends to the originating entity when it verifies, in the information received electronically, the existence of any of the causes for return or rejection provided below.

i) Causes.

Account does not exist.
Branch/entity/destination does not exist.
Format error.
Incorrect amount.
Currency different from the credit account currency.
Beneficiary request.
Branch not enabled.
Duplicate transaction.
Error in additional record.
Error in mandator field.
CUIT, CUIL, or CDI of the beneficiary does not match.
Does not correspond to salaries.
Error in field 11 of the batch header "Check Digit".
Entity code incompatible with transaction currency.
Non-working day.
Request by the originating entity.

ii) Return or rejection deadlines.
In all cases, the deadline to effect the return or rejection of a transfer is 24 hours, from the time of its receipt.
It must be taken into account that the procedure to perform a rejection or a return differs depending on the type of transfer.
For Salary Payments, Pension Payments, Family Allowances, Seizures of wages by judicial order, and Retail Transfers (Payments to suppliers and between clients or clients and third parties), denominated in pesos, there is only the presentation session, so the returns of these will be carried out in that single session by presenting a new transfer, the day after the original transfer was issued. Retail Transfers for Payments to suppliers and between clients or clients and third parties, denominated in foreign currency, have a presentation session and a rejection session, so the rejections will be issued the day after the presentation in the corresponding rejection session.

The 24-hour return deadline can only be exceeded in the case that the return is requested by express request of the receiving client. The maximum deadline to effect the return, through the CEC, of a transfer is 30 calendar days, and will be carried out by means of a bilateral agreement agreed upon by the entities involved on each occasion.

iii) Operational instructions. a) Transmission of returned or rejected transfers.
The receiving entity will transmit to the CEC, by the cutoff time of the presentation session, the information corresponding to the Salary Payments, Pension Payments, Family Allowances, Seizures of wages by judicial order, and Retail Transfers (Payments to suppliers and between clients or clients and third parties), denominated in pesos, that were returned. The receiving entity will transmit to the CEC, by the cutoff time of the rejection session, the information corresponding to the Retail Transfers (Payments to suppliers and between clients or clients and third parties), denominated in foreign currency, that were rejected.

b) CEC Processing.
The chamber will receive from the receiving entities the information corresponding to the returned or rejected transactions and will execute the electronic clearing process according to the defined schedules.

iv) Return by the originating entity.
In the case that the originating entity requests the return of a transfer sent by it, the return management must be agreed upon between the originating and receiving entities outside the clearing system. As a result of this operation, the receiving entity will send a return of the transfer to the CEC indicating as the reason "Request by the originating entity".

1.4. Responsibilities of the participants.
The entities, whether as originators or receivers, and the CECs, must comply with the following responsibilities:

1.4.1. Financial Entities.
Permanently and online supply the CECs with the base of account holders with their respective CUIT, CUIL, or CDI.

1.4.2. Originating Entity.

Guarantee the fidelity of the information entered into the system.
Generate information according to the defined standards.
Send the information to the CEC within the hours defined by it.
Send a file with null value for each Transmission Center that the entity routinely uses, in case of not having information to send. In this way, the CEC is informed that no transfer has been delivered for clearing during the course of the day.
Be responsible for the storage of supporting documentation for transfer requests.
Credit or pay on the same day the communication is received, the amount corresponding to the properly requested returns of the transfers.
Perform validity controls on the returns of transfers.

1.4.3. CEC.

Assume responsibility for the correct treatment of the information received from the entities and the results of its processing, once the files sent by the entities are validated and accepted.
Perform the corresponding controls on the transactions received and presented to ensure their integrity and accuracy.
Administer the account holders database.
Send the output files to the entities in the defined times.
Present the information to the destination entities according to the defined standards.
Store the processed information in adequate media, to ensure its recovery.
Administer security keys for the transmission and reception of information.
Administer the telecommunications network between its own computer center and the entities' Transmission Centers.
Provide the necessary information to the entities for the calculation of interbank commission billing.

1.4.4. Receiving Entity.

Inform clients of the transfers made in the corresponding medium and timeframe.
Guarantee the fidelity of the information provided to the system.
Ensure the transmission of information according to the defined standards.
Send the information to the CEC within the hours defined by it.
Preserve the information corresponding to the transfers received and returned.
Credit according to the established clearing deadlines, the amount corresponding to the transfers received.
Perform validity controls on the transfers received.
Permanently and online supply the CECs with the base of account holders with their respective CUIT, CUIL, or CDI.
Send a file with null value for each Transmission Center that the entity routinely uses, in case of not having rejections of retail transfers (Payments to suppliers and between clients or clients and third parties, in foreign currency). In this way, the CEC is informed that no rejection related to retail transfers received the previous day has been delivered.
Keep the Transmission Centers that it uses available during all days in which settlement of operations is carried out at the BCRA.
Return the transfers that could not be posted to the receiving clients' accounts, within the established return deadline of 24 hours.

1.5. Controls to be performed.
This point enumerates the controls that the CECs and entities must perform on the files exchanged electronically, in order to ensure the reliability of the data.

1.5.1. CEC.

The existence of the originating entities.
The existence of the receiving entities.
Verify that the entity is affiliated with that CEC.
The control totals of each batch.
The control totals of the file.
The integration of mandatory inclusion fields.
Detect files or batches duplicated by entities on the same day.
Verify the CUIT, CUIL, or CDI of the beneficiary in the account holders database informed by the entities.
Verify that a Retail Transfer (Payments to suppliers and between clients or clients and third parties), denominated in foreign currency, has been previously presented in the case of returns by the receiving entity.

1.5.2. Financial Entities.
1.5.2.1. Entities that receive electronic information.
The entities that receive information from the CEC, whether as receivers in the case of the presentation session, or as originators in the case of the rejection session, must perform the following controls:

The absence of invalid characters.
The information corresponding to the destination entity.
The number of batches in the file.
The integration of mandatory inclusion fields.
The control totals of each batch.
The control totals of the file.
Verify the validity of the return or rejection deadlines.
Verify the validity of the return or rejection causes.
The match of data between the original transaction and its return or rejection.
Verify the non-inclusion of non-working days.

1.5.2.2. Entities that send electronic information.
The entities that send information to the CEC, whether as originators in the case of the presentation session, or as receivers in the case of the rejection session, must perform the following control:

Detection of duplicate file submissions.

1.6. Transactions.
1.6.1. Introduction.
The transactions that will be exchanged electronically between the entities and the CEC will be the following:

Transfer.
Return or rejection.

1.6.2. File Structure.
The structure of the files has been developed considering the standards of the NACHA ("National Automated Clearing House Association"). The files to be exchanged electronically will have the following structure:

File Header.
Batch Header.
Individual Record.
Additional Record.
Batch End Control.
File End Control.

The letter M will be used to indicate that it is a mandatory field and the letter O to indicate optional fields.

The File Header, Batch Header, Batch End Control, File End Control, and Individual Transaction Record records are the same in all files, for any type of transaction related to transfers.

1.6.2.1. File Header.
The file header identifies the immediate origin of the information, which includes the Transmission Center and the originator entity or entity sending the information (which will be the originator in the case of the presentation session and the receiver in the return session).

In this record, the information will be disaggregated depending on whether it is made in pesos or in another currency authorized by the BCRA. At the same time, this record includes the fields for presentation date, presentation time, and the file identifier, so as to identify it uniquely.

1.6.2.2. Batch Header.
The batch header identifies the originator entity and the destination entity of the transaction.
This record also indicates the clearing date of the transactions included in the batch.

The information contained in the batch header applies to all individual records contained within it.

1.6.2.3. Individual Transaction Record.
The individual transaction record contains the necessary information to send the transaction to the destination entity (entity and branch) and the corresponding account.

1.6.2.4. Additional Record.
The additional record is used to provide additional information about the transaction included in the individual record.
In the case of individual records of transfer orders for payments to suppliers, the inclusion of an additional record is optional.
In the case of individual records of transfer orders between clients or clients and third parties, the inclusion of an additional record is mandatory.
In the case of individual records of returns, the inclusion of an additional record is mandatory.

1.6.2.5. Batch End Control.
The batch end control contains the sum of the amounts, records (individual and additional), and control totals of the individual records contained in the batch.
The batch header and batch end record are not included in the aforementioned sum of records.

1.6.2.6. File End Control.
The file end control contains the sum of the amounts, records (individual and additional), and control totals of the batches contained in the file.
The number of batches included in the file is also included.

1.7. Record Design.
1.7.1. File Header.

Field	1	2	3	4	5	6	7	8	9	10	11	12	13
Name	Record Identifier	Priority Code	Immediate Destination	Immediate Origin	Presentation Date	Presentation Time	File Identifier	Record Size	Block Factor	Format Code	Name of Immediate Destination	Name of Immediate Origin	Product Ref. Code
Field Requirement	M	O	O	M	M	M	M	M	M	M	M	M	M
Type	'1'	'01'	Numeric	Numeric	AAMMDD	D	Numeric	Alphanumeric	'094'	'10'	'1'	Alphanumeric	Alphanumeric	Alphanumeric
Length	1	2	10	10	6	4	1	3	2	1	23	23	8
Position	01-01	02-03	04-13	14-23	24-29	30-33	34-34	35-37	38-39	40-40	41-63	64-86	87-94

Description of the fields:

Record Identifier.
This code is assigned to identify the type of record:
a. File Header.
Priority Code.
This code was defined for possible future use. Currently, '01' is used in all cases.
Immediate Destination.
Identifies the destination of the file. When the entity transmits to the chamber, this field contains:
a) A blank space. b) The identifying number of the CEC in 8 positions. To the identifying number of the CEC, '500' is added in the first four positions when sending transactions in US dollars. c) A zero.

In the case where the chamber is the one transmitting, this identifying number will be composed of:
a) A blank space. b) The destination entity number in 4 positions. To the identifying number of the entity, '500' is added in the first four positions when sending transactions in US dollars. c) The entity branch number acting as Transmission Center in 4 positions. d) A zero.

Immediate Origin.
Identifies the origin of the file. When the chamber transmits to the entity, this field contains:
a) A blank space. b) The identifying number of the CEC in 8 positions. To the identifying number of the CEC, '500' is added in the first four positions when sending transactions in US dollars. c) A zero.

In the case where the entity is the one transmitting to the CEC, this identifying number will be composed of:
a) A blank space. b) The origin entity number in 4 positions. To the identifying number of the entity, '500' is added in the first four positions when sending transactions in US dollars. c) The entity branch number acting as Transmission Center in 4 positions. d) A zero.

Presentation Date.
This field contains the date on which the file was created.
Presentation Time.
This field contains the time at which the file was created.
File Identifier.
This field allows differentiating the multiple files created on the same date and among the same participants, by including an order code which can be letters or numbers (A-Z or 0-9).
Record Size.
This field would indicate the number of characters contained in each record. Currently, the number '094' is used.
Block Factor.
This field defines the number of physical records that exist in a block (a block is composed of 940 characters). All transmissions between the entities and the chamber must use the number '10'.
Format Code.
This field is reserved for future use. It must be completed with the value '1'.
Name of Immediate Destination.
This field contains the name of the file destination (Electronic Chamber / Transmission Center, as applicable).
Name of Immediate Origin.
This field contains the name of the message originator. (Electronic Chamber / Transmission Center, as applicable).
Product Reference Code.
This field contains the product reference code. The possible products are - SUE - for Salary Payments, Pension Payments, Family Allowances, and Seizures of wages by Judicial Order, and - MIN - for retail transfers Payments to Suppliers and between Clients or Third Parties and payments by judicial order. In the first 3 positions, the transfer reference code will be completed in uppercase, SUE or MIN, and the remaining 5 positions will be completed with blanks.

Additional Comments:
When a field has more characters than required to complete the information, they must be filled with zeros starting from the left margin, in the case of numeric fields, and with blanks to the right in the case of alphanumeric fields. The alphabetic characters of the alphanumeric fields must always be reported in uppercase.

1.7.2. Batch Header.

Field	1	2	3	4	5	6	7	8	9	10	11	12	13
Name	Record Identifier	Transaction Class Code	Company/Individual Name	Discretionary Information at Company's Discretion	Company/Individual Identification	Standard Record Type Code	Reserved	Submission Date	Settlement Date	Transaction Currency/Transfer Type	Check Digit	Originating Entity Identification	Batch Number
Field Requirement	M	O	M
Type	'5'	'220'	Alphanumeric	Alphanumeric	Numeric	'CCD'	Alphanumeric	AAMMDD	AAMMDD	Alphanumeric	Numeric	Numeric	Numeric
Length	1	3	16	20	10	3	10	6	6	3	1	8	7
Position	01-01	02-04	05-20	21-40	41-50	51-53	54-63	64-69	70-75	76-78	79-79	80-87	88-94

Field Descriptions:

Record Identifier.
This code is assigned to identify the type of record:
5 Batch Header.
Transaction Class Code.
This code identifies a general classification of the types of transactions included in the batch:
220 Credit transactions.
Company/Individual Name.
Identifies the company or individual originating the message or transaction. In the case of transfers originated by an individual, this field will be completed with the word "PARTICULARES".
Discretionary Information at Company's Discretion.
This field will be used by the originating company to incorporate additional information at its discretion.
Company/Individual Identification.
This field contains the unique tax identification key (CUIT) of the company. The check digit will be incorporated in field 11. When the transfer is initiated by an individual, this field will be completed with zero (0).
Standard Record Type Code.
This code allows distinguishing the type of record:
CCD Transactions corresponding to the Salary Transfers product.
CTX Transactions corresponding to the Retail Transfers product.
Reserved.
Reserved for future use. It should be noted that in the case of "unwinding" of transfers, the clearinghouses will complete this field with the literal REVERSALS.
Submission Date.
This field contains a date established by the originator with the objective of providing information about the original transaction.
Settlement Date.
This field contains the settlement date of the transfer.
Transaction Currency/Transfer Type.
This field identifies the transaction currency and the type of transfer. It will be completed as follows:
The first position will always be completed with zero (0).
The second position will be completed with zero (0) for transactions in pesos, with one (1) for transactions in US dollars, and with two (2) for transactions in euros.
The third position will be completed according to the type of transfer, namely:
0.- Salary Returns.
1.- Salary Payments.
2.- Payments to Suppliers.
3.- Transfers between Clients or Third Parties.
4.- Family Allowances.
5.- Pension Payments.
6.- Returns of Pension Payments.
7.- Returns of Payments to Suppliers.
8.- Returns between Clients and/or Third Parties.
9.- Returns of Family Allowances.
A.- Embargoes on wages by judicial order.
B.- Returns of Embargoes on wages by judicial order.
C.- Transfers by judicial order.
D.- Returns of Transfers by judicial order.
Check Digit.
This field contains the check digit of the CUIT that identifies the originating company or zero (0) in case field 5 was completed with zeros (transfers between third parties).
Originating Entity Identification.
This field contains the identification number of the entity originating the record (it includes the entity number with 4 characters and the branch number with 4 characters). When transactions in US dollars are sent to the entity identification number, 500 is added to it.
Batch Number.
This field contains the batch number, determined by the originating entity.

Additional Comments:
When a field has more characters than required for the information to be completed, they must be filled with zeros starting from the left margin, in the case of numeric fields, and with spaces to the right in the case of alphanumeric fields. The alphabetic characters of the alphanumeric fields must always be reported in uppercase.

1.7.3. Individual Record of Transfer Orders and Returns of Transfer Orders.

Field	1	2	3	4	5	6	7	8	9	10	11
Name	Record Identifier	Transaction Code	Entity to Credit	Reserved	Account to Credit	Amount	Unique Transfer Reference	Beneficiary Client Identification	Transaction Currency/Transfer Type	Additional Records	Record Counter
Field Requirement	M
Type	'6'	Numeric	Numeric	Numeric	Numeric	$$$$$$$	$cc	Alphanumeric	Alphanumeric	Numeric	Numeric	Numeric
Length	1	2	8	1	17	10	15	22	2	1	15
Position	01-01	02-03	04-11	12-12	13-29	30-39	40-54	55-76	77-78	79-79	80-94

Field Descriptions:

Record Identifier.
6 Individual Record.
Transaction Code.
This code indicates the type of transaction reported and the type of account involved in the transaction:

Transactions/Returns	Rejections/Camera "Unwinding" Rejects
32	31 37

Entity to Credit.
This field contains the identification number of the destination entity of the transaction (it includes the entity number with 3 characters preceded by a zero -"0"- and the branch number with 4 positions). The identification number of the entity is added 500 when transactions in US dollars are sent.
Reserved.
This field must be completed with a zero "0".
Account to Credit.
This field indicates the account to be credited, and must contain the exact data of the same. These data will be taken from block two of the Uniform Banking Key (CBU) including its check digit. Numbers from 0 to 9 are included, aligned to the right.
Amount.
This field indicates the amount to be credited to the account detailed above.
Unique Transfer Reference.
This field indicates the reference by means of which the company or individual uniquely identifies the transfer to be made.
It must be completed with the 12-position free alphanumeric codes defined in Section 3.
Beneficiary Client Identification.
The beneficiary client of the transfer is uniquely identified, either with their CUIT, CUIL, or CDI number. The field will be composed as follows:
a) In the first position to the left, the type of key code:
1 - CUIT.
2 - CUIL.
3 - CDI. b) In the next 11 positions, the fiscal key number. c) 5 blank spaces. d) The last three positions will be completed as follows: the first position with a "0" and the remaining two with the BCRA operation code:
73- Transfers to credit in accounts for taxable operations.
74- Transfers to credit in accounts for non-taxable operations.
75- Transfers for salary payments.
Transaction Currency/Transfer Type.
This field identifies the transaction currency and the type of transfer. It will be completed as follows:
The first position will be completed with zero (0) for transactions in pesos, with one (1) for transactions in US dollars, and with two (2) for transactions in euros.
The second position will be completed according to the type of transfer, namely:
0.- Salary Returns.
1.- Salary Payments.
2.- Payments to Suppliers.
3.- Transfers between Clients or Third Parties.
4.- Family Allowances.
5.- Pension Payments.
6.- Returns of Pension Payments.
7.- Returns of Payments to Suppliers.
8.- Returns between Clients and/or Third Parties.
9.- Returns of Family Allowances.
A.- Embargoes on wages by judicial order.
B.- Returns of Embargoes on wages by judicial order.
C.- Transfers by judicial order.
D.- Returns of Transfers by judicial order.
Additional Records.
This field indicates whether there are additional records ('1' or '0' respectively).
Record Counter ("Trace number").
This field includes the originating entity's identification number in 8 positions (4 for the entity and 4 for the branch) and then in positions 9 to 15 a unique ascending sequential number in all sessions of the day for each record sent in a file. This implies that the record counter number can repeat in different files transmitted throughout the day. These 15 positions must be ordered sequentially within each batch. The identification number of the entity is added 500 when transactions in US dollars are sent. In case an entity represents another for the submission of checks, the branch number will be replaced by a "9" in the fifth position and the represented entity number in the following positions.

1.7.4. Additional Record of Transfer Orders and Returns.

Field	1	2	3	4	5
Name	Record Identifier	Additional Record Type Code	Concept	Additional Record Sequence Number	Individual Record Sequence Number
Field Requirement	M
Type	'7'	'05'	Alphanumeric	Numeric	Alphanumeric
Length	1	2	80	4	7
Position	01-01	02-03	04-83	84-87	88-94

Field Descriptions:

Record Identifier.
This code is assigned to identify the type of record:
7 Additional Record.
Additional Record Type Code.
This code indicates the type of additional record. In the case of transfer files, the code '05' is used.
Concept.
This field will be completed as follows:
For the submission of Transfers between Clients and/or Third Parties:
In the first 11 positions, the CUIT, CUIL, CDI, or DNI number of the originator of the movement will be reported, and in the next 22 positions, their name and surname.
When the transfer is a return of Salary Payment, Pension Payments, Family Allowances, and Embargoes on wages by judicial order, the data corresponding to the original transaction will be reported:

In the first 6 positions, the date: taken from the Batch Header record, field 8 – Date reported by originator, corresponding to the submission of the transaction;
In the next 8 positions, the number of the entity to credit, aligned to the right: taken from the individual record of the transfer, field 3 - entity to credit, corresponding to the submission of the transaction.
In the next 15 positions, the record counter, aligned to the right: taken from the individual record of the transfer, field 11 – Record Counter, corresponding to the submission of the transaction.
In the next 3 positions, the reason for return.
In the remaining 49 positions, blanks.
When the transfer is a return of Retail Transfers (Payments to Suppliers and between Clients and/or Third Parties and Payments by judicial order), in pesos, the data corresponding to the original transaction will be reported:
In the first 6 positions, the date: taken from the Batch Header record, field 8 – Date reported by originator, corresponding to the submission of the transaction;
In the next 8 positions, the number of the entity to credit, aligned to the right: taken from the individual record of the transfer, field 3 - entity to credit, corresponding to the submission of the transaction.
In the next 15 positions, the record counter, aligned to the right: taken from the individual record of the transfer, field 11 – Record Counter, corresponding to the submission of the transaction.
In the next 3 positions, the reason for return. According to the description indicated in field 3 "Reason for return", of the Additional Record of Rejections of Transfer Orders.
In the remaining 49 positions, blanks.

Sequence Number.
Consecutive number assigned to each additional record following an individual record.
Individual Record Sequence Number.
Indicates the last 7 positions of the record counter ("trace number") of the individual transaction record.

1.7.5. Additional Record of Rejected Transfer Orders.

Field	1	2	3	4	5	6	7	8
Name	Record Identifier	Additional Record Type Code	Reason for Return or Rejection	Original Transaction Record Counter	Reserved	Entity of Original Transaction	Additional Information	Record Counter
Field Requirement	M	N/A	M	O	M
Type	'7'	'99'	Alphanumeric	Numeric	Blank	Numeric	Alphanumeric	Numeric
Length	1	2	3	15	6	8	44	15
Position	01-01	02-03	04-06	07-21	22-27	28-35	36-79	80-94

Field Descriptions:

Record Identifier.
This code is assigned to identify the type of record:
7 Additional Record.
Additional Record Type Code.
This code indicates the type of additional record. In this case, the code '99' is used.
Reason for Return or Rejection.
This field describes the reason why a transaction is returned by the entities or by the entities and the clearinghouses through the use of a code.

CODE	DESCRIPTION	EXPLANATION
R03	Non-existent Account	Used by the receiving entity in the case that the account on which the transaction falls is not active within the entity's database.
R13	Non-existent Entity/Branch	Used by receiving entities and by clearinghouses in the case that the entities to which transactions are sent or from which they are received cannot be identified. Used by clearinghouses for the following reasons: Omitted or erroneous transaction description, non-numeric destination, non-numeric record counter, additional record identification different from "0" or "1", first byte of TRX code invalid, no detail TRX in the batch, invalid record type code, invalid character in header or end of file/batch, invalid character in individual or additional record, transaction not NACHA found in file, invalid record type, non-numeric or invalid destination entity, second byte of transaction code invalid, difference in batch control totals, invalid return code, invalid number of additional records for transaction.
R17	Format Error	Used by receiving entities to reflect format errors in mandatory and/or fixed fields and when receiving special alphabetic characters not admitted or in lowercase. Used by clearinghouses when the amount is non-numeric or equal to zero.
R19	Incorrect Amount	Used by the receiving entity when the amount of a return does not coincide with the amount of the original transaction.
R20	Currency Different from Credit Account Currency	Used by the receiving entity when transactions fall on accounts of different currencies.
R22	Beneficiary Client Request	Used by the receiving entity to return transfers at the request of the beneficiary client of the same.
R23	Branch Not Enabled	Used by the receiving entity when receiving transfers on a branch not enabled.
R24	Duplicated Transaction	Used by the receiving entity when receiving duplicated transactions. Used by clearinghouses for the reasons: Additional record out of sequence, erroneous combination of additional records, additional record exists and is not included, required additional record not present, transaction other than rejection.
R25	Error in Additional Record has Additional "99".	Used by the receiving entity when there is a problem with additional records when they are mandatory, when the presence of the additional record is indicated and it does not exist, etc.
R26	Error in Mandatory Field	Used by the receiving entity when a mandatory field is blank or with invalid characters.
R40	CUIT, CUIL, or CDI Mismatch	Used by clearinghouses or by the receiving entity when the CUIT, CUIL, or CDI indicated in the transfer is incorrect or does not coincide with the corresponding one of any of the holders of the receiving account.
R45	Does Not Correspond to Salaries	Used by the receiving entity when the transaction does not correspond to the salary payment system.
R76	Error in Field No. 11 of Batch Header "Check Digit"	Used by receiving entities and by clearinghouses when there is an error in this field intended for the check digit of the CUIT, CUIL, or CDI of the originator of the transfer. Used by clearinghouses when the bank code is incompatible with the transaction currency.
R91	Entity Code Incompatible with Transaction Currency.	Used by the receiving entity when entity numbers are not expressed in all cases in the same currency.
R93	Non-Working Day	Used by the receiving entity when the received information cannot be processed for some branch whose schedule has a holiday or local closure.
R98	Originating Entity Request	Used by the receiving entity to return transfers at the request of the originating entity.

This field describes the reason why a transaction is returned by the clearinghouses through the use of a code.

CODE	DESCRIPTION	EXPLANATION
R13	Non-existent Destination Entity	Used when the entity of the record counter and/or transmission center do not exist, the destination entity does not exist, or differs from a numeric value.
R27	Error in Record Counter	Used when the record counter differs in individual or additional records and when there is a sequence problem in the same.
R31	Clearinghouse Rollback (Unwinding)	Used when movements must be returned due to the need to reprocess the clearinghouse, given that a bank did not cover the debit position.
R75	Invalid Date	Used when there are date format errors.
R77	Error in Field No. 4 of Individual Record	Used when field 4 (reserved) of the individual record contains a value different from "0".
R78	Error in Field No. 5 of Individual Record (Account to Credit)	Used when there is a format error in the account number (non-numeric or zero).
R79	Error in Unique Transfer Reference	Used when the unique transfer reference has not been completed.
R87	Invalid Currency	Used when field No. 9 of the Individual Record (1st byte) includes data other than "0" or "1".
R88	Error in Field No. 2 of Individual Record (Transaction Code)	Used when an incorrect transaction code is reported.
R90	Transaction Does Not Correspond Due to Non-existence of Original Transaction	Used when returns are received on non-existent transactions.

Original Transaction Record Counter.
This field carries the record counter of the transaction being rejected.
Reserved.
This field is reserved for future use.
Entity of Original Transaction.
This field contains the identification of the entity that transmitted the original transaction, with the following format:
a) The entity number in 4 positions. b) The branch number established by the origin entity in 4 positions.
Additional Information.
This field contains additional information that clarifies the reason for the return.
Record Counter ("Trace number").
This field contains the same Record Counter as its corresponding Individual Record.

1.7.6. Batch End Control.

Field	1	2	3	4	5	6	7	8	9	10	11
Name	Record Identifier	Transaction Class Code	Number of Individual/Additional Records	Control Totals	Total Batch Debits	Total Batch Credits	Company/Individual Identification	Reserved	Reserved	Originator Identification	Batch Number
Field Requirement	M	N/A	N/A	M	M
Type	'8'	'220'	Numeric	Numeric	$$$$$$$$	$$cc	$$$$$$$$	$$cc	Alphanumeric	Alphanumeric	Alphanumeric	Numeric	Numeric
Length	1	3	6	10	12	12	10	19	6	8	7
Position	01-01	02-04	05-10	11-20	21-32	33-44	45-54	55-73	74-79	80-87	88-94

Field Descriptions:

Record Identifier.
This code is assigned to identify the type of record:
8 Batch End Control
Transaction class code.
This code identifies a general classification of the type of transactions included in the batch:
220 Credit transactions
Number of individual and additional records.
This field contains the total number of individual and additional records existing in the batch.
Control totals.
This field contains the sum of the "entity to be credited" field from the individual records of the batch.
Total sum of batch debits.
This field contains the sum of the debit amounts included in the batch. If the sum exceeds the available number of characters, another batch must be generated.
Total sum of batch credits.
This field contains the sum of the credit amounts included in the batch. If the sum exceeds the available number of characters, another batch must be generated.
Identification of the company/individual.
This field contains the unique tax identification key (CUIT) of the company (the check digit will not be included). When the transfer is initiated by an individual, this field will be completed with the number 0.
Reserved.
This field is reserved for future use.
Reserved.
This field is reserved for future use.
Identification of the originating entity.
This field contains the identifying number of the entity originating the record (it includes the entity number with 4 characters and the branch number with 4 characters). When transactions in dollars are sent to the entity number, 500 will be added to it.
Batch number.
This field contains the batch number, determined by the originating entity.

Additional comments:
When a field has more characters than required to complete the information, they must be filled with zeros starting from the left margin, in the case of numeric fields, and with spaces to the right in the case of alphanumeric fields. The alphabetic characters of the alphanumeric fields must always be reported in uppercase.

1.7.7. End of file control.
Field 1 2 3 4 5 6 7 8
Name Record Identifier
Number of batches
Number of blocks
Number of individual and additional records
Control totals
Total sum of debits of the file
Total sum of credits of the file
Reserved
Field
Requirement
M N/A
Type '9' Numeric Num- eric Numeric Num- eric $$$$$$$$ $$cc $$$$$$$$ $$cc Blank Length 1 6 6 8 10 12 12 39 Position 01-01 02-07 08-13 14-21 22-31 32-43 44-55 56-94 Description of the fields:

Record Identifier.
This code is assigned to identify the type of record:
9 End of File Control
Number of batches.
This field contains the total number of batches existing in the file.
Number of blocks.
This field contains the total number of blocks in the file. A block is composed of 940 characters, that is, 10 records would form a block. For this count, all records are considered, from the file header to the End of File Control. When the number of records is not a multiple of 10, this total will be calculated as follows:

Up to 10 records 1
Up to 20 records 2, and so on consecutively.
4. Number of individual and additional records.
This field contains the total number of individual and additional records existing in the file.
5. Control totals.
This field contains the sum of the "Control totals" field from the control records of all batches.
6. Total sum of file debits.
This field contains the sum of the debit amounts included in the file. If the sum exceeds the available number of characters, another file must be generated.
7. Total sum of file credits.
This field contains the sum of the credit amounts included in the file. If the sum exceeds the available number of characters, another file must be generated.
8. Reserved.
This field is reserved for future use.

1.7.8. Transaction encoding.
Header
File Header Batch Header Individual Record Currency Transaction Field 13 Field 6 Field 7 Field 10 Field 2 Field 9 Transfers Salary Payments Presentation SUE CCD 001 32 01 Return SUE CCD 000 32 00 Reject of chamber SUE CCD 001 31 01/00 Transfers Family Allowances Presentation SUE CCD 004 32 04 Return SUE CCD 009 32 09 Reject of chamber SUE CCD 004 31 04/09 Transfers Provisional Payments Presentation SUE CCD 005 32 05 Return SUE CCD 006 32 06 Reject of chamber SUE CCD 005 32 05/06 Transfers Embargoes Presentation SUE CCD 00A 32 0A Return SUE CCD 00B 32 0B Reject of chamber SUE CCD 00A 31 0A/0B Transfers Between Clients or Third Parties Presentation MIN CTX 003 32 03 Return MIN CTX 008 32 08 Reject of chamber MIN CTX 003 31 03/08 Unwinding Presentation MIN CTX REVERSAL 003 37 03 Unwinding Return MIN CTX REVERSAL 008 37 08 Transfers Payments to Suppliers Presentation MIN CTX 002 32 02 Return MIN CTX 007 32 07 Reject of chamber MIN CTX 002 31 02/07 Unwinding Presentation MIN CTX REVERSAL 002 37 02 Unwinding Return MIN CTX REVERSAL 007 37 07 Transfers by Judicial Order Presentation MIN CTX 00C 32 0C Return MIN CTX 00D 32 0D Reject of chamber MIN CTX 00C 31 0C/0D Unwinding Presentation MIN CTX REVERSAL 00C 37 0C PESOS Unwinding Return MIN CTX REVERSAL 00D 37 0D

Transfers Between Clients or Third Parties
Presentation MIN
C
T
X 013 32 13
Rejection or reject of chamber MIN
C
T
X 013 31 13
Transfers Payments to Suppliers
Presentation MIN
C
T
X 012 32 12
M
O
NED
A
EX
T
R
A
NJ
E
R
A
1-D
ÓLA
R
E
S
2-EU
R
O
S
Rejection or reject of chamber MIN
C
T
X 012 31 12/13

Section 2. Immediate transfers.
2.1. Introduction and objective.
2.1.1. This section aims to define the operational instructions related to
immediate transfers.
2.1.2. Immediate transfers will aim to provide customers with a transfer service that debits and credits the amount instantly - improving customer service through the application of international standards - contributing to the security and efficiency of the National Payments System.
2.2. Characteristics.
2.2.1. The immediate transfer service must be made available to their customers
by all financial entities and PSPs that offer payment accounts.
2.2.2. Financial entities will enable, at a minimum, the following electronic channels
for the immediate transfer service:

Automated Teller Machine (ATM)
Mobile Banking (MB)
Internet Banking (IB)
2.2.3. Operating hours: immediate transfers can be ordered by the customer
during the 24 hours of the day, every day of the year.
2.2.4. Minimum limits: immediate transfers can be processed per day and per account
without the need for special requests up to the amounts detailed in
Section 6. of the rules "National Payments System – Transfers – Complementary Rules". Financial entities cannot establish limits lower than those indicated above, without prejudice to the fact that they may increase them. Additionally, for cases where they need it for specific operations, customers may request – remotely or in person – the temporary expansion of such limits, prior to the execution of the transfer.
2.2.5. Prices to customers: immediate transfers will be covered by the
price scheme to customers detailed in Sections 5. and 6. of the rules "National Payments System – Transfers – Complementary Rules".
2.2.6. Security: in accordance with what is established in the rules on "Minimum requirements for management, implementation and control of risks related to information technology, information management and associated resources for financial entities", financial entities must satisfy the technical-operational security requirements established in Section 6.
2.2.7. Constitution and settlement of guarantees: what is stipulated by the BCRA in the corresponding regulation for the immediate transfer product applies.
2.2.8. Cut-off times for compensation: the cut-off times of the operation, intended to
compensate the amounts in the accounts of financial entities, will be defined by the administrator of each immediate fund transfer scheme.
2.2.9. Currencies: immediate transfers will be available in pesos and US dollars; between accounts of the same currency.

2.2.10.Active account inquiry: in order to avoid errors in identifying the receiving accounts, as well as to verify the enablement of the destination account at the time of authorization of an immediate transfer, each payment scheme must put at disposal of its participants a service for active account inquiry. 2.2.11.Transaction queuing: it will not be allowed for 'Payment with transfer', the payment request, nor the withdrawals defined in Section 3. of the rules "National Payments System – Transfers – Complementary Rules" and will be admissible for immediate transfers with the agreement of the ordering customer. The queuing of an immediate transfer can only be determined at the time of its authorization; after the determination of the queuing of the transaction, the payment schemes will determine the flow to follow. 2.2.12.Credit periods: the resolution of each immediate transfer must be carried out in no more than 15 seconds, including the confirmation or rejection notifications to the ordering and receiving customers as appropriate. 2.2.13.Transaction audit: each transfer scheme will implement the means necessary so that in case of failure in a transfer, the point of failure can be identified and take corrective actions pre-established in each case and leave the transaction resolved immediately. The corrective actions must always have resolution within the scheme itself. 2.2.14.According to the previous points, the authorization function for immediate transfers will consider, among others, the availability of sufficient funds in the account of origin, the daily limits, the concordance of the currency of the accounts, the availability of sufficient guarantee funds, the enablement of the destination account, the need for queuing and the fraud mitigation tools. Regarding the availability of sufficient funds in the account of origin, this can be determined by the account provider strictly based on the available balance at that instant in the payment account, or, when it comes to demand accounts in financial entities, on the available balance plus the pre-agreed credit lines; it will not be possible to authorize an immediate transfer based on the expectation of future credits in the account, even if these occur on the same day or are under the full control of the same provider of the account. The administrators of immediate transfer schemes must monitor authorization patterns, in order to prevent any type of discrimination towards certain acceptors or originating entities, providing in their contracts the application of fines when they detect these breaches. The administrators must also provide in their contracts fines to be borne by the account providers, whether financial entities or PSPs, when the authorization of the immediate transfers does not occur in the time and manner established in the regulation. 2.2.15.The immediate transfer service must have an operational availability for all customers of at least 99.92% of the time, in line with
international standards of the Payments and Market Infrastructures Committee of the Bank for International Settlements. 2.2.16.Each immediate transfer will have the descriptions and information detailed in
Section 3.
2.3. Responsibilities of participants.

2.3.1. Participating entities, whether in the capacity of originators or receivers and PSPs
must arrange appropriate security mechanisms within their competence to ensure the transmission and reception of transactions, as well as they will have the following responsibilities:
2.3.2. Administrator of an immediate transfer scheme:
2.3.2.1. Take the necessary operational precautions to achieve the required performance and availability standards.
2.3.2.2. Define the procedures, cycles and cut-off times for compensation.
2.3.2.3. Make available to its participants, and to other schemes when appropriate, a service for active account inquiry.
2.3.2.4. Ensure the monitoring of the availability of sufficient guarantee funds.
2.3.2.5. Establish the necessary fines to incentivize adherence to the rules of the
payment scheme by all participants.
2.3.2.6. Establish rules for the handling of returns and situations where there is a suspicion of fraud.
2.3.2.7. Implement the necessary transaction audit procedures so that,
in case of failure in a transfer, the point of failure can be identified, take corrective actions pre-established in each case and leave the transaction resolved immediately.
2.3.2.8. Offer fraud mitigation tools to its participants.
2.3.3. Originating and/or receiving entity, PSP that offers payment accounts:
2.3.3.1. Guarantee the availability of immediate transfers for all their
customers who can be ordered or received during the 24 hours of the day, every day of the year.
2.3.3.2. Take the necessary operational precautions to achieve the required performance and availability standards.
2.3.3.3. Ensure monitoring for each transaction of the availability of sufficient guarantee funds.
2.3.3.4. Keep updated the information used by the services for active account inquiry of the schemes in which they participate.
2.3.3.5. Use fraud mitigation tools that allow identifying suspicious patterns, and alerting users.
2.3.4. Acceptor within an immediate transfer scheme:
2.3.4.1. Offer its immediate transfer acceptance services discriminating
the price of commissions for each specific payment instrument, refraining from packaging it with other instruments so that they reflect the economic costs of each one and facilitate the search for more efficient alternatives.

2.3.4.2. Take the necessary operational precautions to achieve the required performance and availability standards.
Section 3. Electronic fund transfers: unique references, information to customers and
description of operations.
3.1. Unique references.
3.1.1. Unique references allow identifying the concepts of the transfers to be made.
3.1.2. The functionalities that require the entry of transfer data must
allow selecting between the following concepts, when they are consistent with the client profile:

Rentals (ALQ)
Capital contributions (APC)
Habitual registrable goods (BRH)
Non-habitual registrable goods (BRN)
Installments (CUO)
Expenses (EXP)
Invoices (FAC)
Benefits (HAB)
Fees (HON)
Real estate operations (OIN)
Habitual real estate operations (OIH)
Loans (PRE)
Reimbursements from social security and prepaid plans (ROP)
Insurance (SEG)
Insurance claims (SIS)
Subscription of negotiable obligations (SON)
Various (VAR).
3.1.3. For the case of payment operations with transfers, it will be used when appropriate.
Payment with Transfer (PCT)
Purchase with Transfer (CCT)
Return with Transfer (DCT)
Withdrawal with Transfer (ECT)
3.2. Information to the client and description of the operations.
3.2.1. The minimum information to be supplied to the client, regardless of the channel or means of communication used, must be the following:
3.2.1.1. For the originator of the transfer:
The total amount transferred.
The date of the transfer.
The name of the receiving client. When available, the
Fantasy Name will be recorded, instead of the name of the account holder.
The CUIT, CUIL, CDI number of the receiving client.
Unique reference of the transfer.
3.2.1.2. For the receiver of the transfer:
The total amount transferred.
The date of the transfer.
The name of the ordering client. When available, the
Fantasy Name will be recorded, instead of the name of the account holder.
The CUIT, CUIL, CDI number of the ordering client.
Unique reference of the transfer.
3.2.1.3. In no summary, account statement or other form of information communication, in printed or digital form, that is supplied to the clients
ordering or receiving can the phrase "Except for error or omission" or similar be incorporated to describe electronic fund transfers.
3.2.2. Particular cases.
3.2.2.1. The originating entities, which debit the accounts of their customers for transfers for Salary Payments, Provisional Payments, Family Allowances,
Embargoes on benefits by judicial order and Payments to suppliers, will agree with them on how they will inform the detail of the movements distributed to the different receiving entities of the funds, having to inform as a movement in the account the total amount debited.
3.2.2.2. In case of referencing a batch transfer between clients or clients and third parties, the information to be supplied to the receiving client (regarding the number of
CUIT, CUIL, CDI of the originator) must be obtained from the Additional Record of the transfer, field 3 "Concept", the first 11 positions.
3.2.2.3. Likewise, they must include for receiving and ordering clients, in the electronic channels that allow periodic consultation linked to account movements, the data of the transfers within a period no greater than 24 hours
from the crediting of funds.
3.2.3. Descriptions for "Payment with transfer":
3.2.3.1. Both in summaries and in any account statement, in printed or digital form, that is supplied to the ordering or receiving clients, in addition to the information described in points 3.2.1.1. and 3.2.1.2. the operations of "Payment with transfer" defined in
Section 3. of the rules "National Payments System – Transfers – Complementary Rules" must be individualized.
3.2.3.2. These transfers must be identified as "Payment with Transfer" or "Purchase with Transfer" as appropriate, or at minimum must be
identified as "Payment CT" or "Purchase CT".
3.2.3.3. For the returns that are practiced, the description "Return Payment with transfer" or "Return PCT" followed by the name of
who was the receiving client or their fantasy name must be included.
3.2.4. Specific descriptions for social assistance initiatives of the public administration.

3.2.4.1. 'Family allowances'. Transfers for family allowances must be identified with the legend "ANSES SUAF/ UVHI"
3.2.4.2. 'Emergency Assistance Program for Employment and Production'. The fund transfers made on the occasion of credits linked to the
"Emergency Assistance Program for Employment and Production" (Decree N°332/2020) must be identified with the concept "ATP National Government".
Section 4. Cards for access to demand accounts.
Financial entities must provide their customers with a card for access to their demand accounts, which allows –among other services– to make immediate transfers of funds, including the 'Payments with transfer' according to Section 3 of the rules on "National Payments System – Transfers – Complementary Rules".

-IndexSection 1. Electronic fund transfers. Basic concepts.
1.1. Introduction and objective.
1.2. General provisions
1.3. Functions of electronic fund transfer schemes.
1.4. Participants and clients of electronic fund transfer schemes.
1.5. General responsibilities of participants.
1.6. Surveillance.
Section 2. Immediate transfers.
Section 3. Immediate transfers: Payment with Transfer, payment request and withdrawals.
3.1. General considerations.
3.2. Payment with Transfer, initiation by the acceptor.
3.3. Payment Request with Transfer.
3.4. Cash withdrawals.
Section 4. Standardized Payment Interface (SPI).
Section 5. Electronic fund transfers, commercial rules.
5.1. General definitions.
5.2. Payment with transfer.
5.3. Withdrawals.
Section 6. Electronic fund transfers: operational variables, prices and interchange rates.
6.1. Minimum limits and equivalences with Value Acquisition Units (UVA).
6.2. Initial free tier.
6.3. Payment with transfer, prices and interchange rates.
6.4. Valid reasons for rejection by the receiving entity for operations in
foreign currency.
6.5. Participants of electronic fund transfer schemes with special character for the purposes of their treatment by the administrators.
Section 7. Adaptation and implementation deadlines.
7.1. Adaptation plan.
7.2. Implementation deadlines.
B.C.R.A.
National Payments System – Transfers –
Complementary Rules
Annex II to
Com. "A"
7153

Section 1: Electronic Fund Transfers. Basic Concepts.

1.1. Introduction and Objective.

1.1.1. This section aims to define the general principles governing the operation of electronic fund transfers between deposit accounts held at financial institutions (hereinafter demand deposit accounts) and even payment accounts. Electronic fund transfers covered by these regulations are retail payment instruments; therefore, payments between financial institutions and with the Central Bank of the Argentine Republic (BCRA), which are considered wholesale, are excluded.

1.1.2. This payment instrument is open and can also be used to perform electronic fund transfers for non-commercial purposes; thus, its objective is to provide customers with a service that allows the transfer of funds between accounts, regardless of who the account holders are or which financial institutions or Payment Service Providers offer the accounts.

1.2. General Provisions.

1.2.1. Functional approach: This regulation shall apply by function within a payment scheme, so that it is homogeneous for different types of entities that perform the same function and therefore compete, whether they are financial institutions or payment service providers (PSPs). Financial institutions and PSPs may perform multiple functions within a payment scheme as long as these regulations do not expressly limit them.

1.2.2. Payment Service Providers by function: Electronic fund transfers may have multiple alternative payment schemes, and each scheme must have its respective administrator, in accordance with the definitions in point 1.2. of the regulations on “Payment Service Providers”.

1.2.2.1. Payment Service Providers are considered to be legal entities that, without being financial institutions, perform at least one function within a retail payment scheme, within the global framework of the National Payments System.

1.2.2.2. Payment schemes are systems of commercial, technical, and/or operational rules that make the operation of a payment instrument possible when at least three parties are involved: an initiator, a beneficiary, and one or more financial institutions or PSPs. Every payment scheme must have an administrator who defines these rules and is responsible for their compliance with the current legal and regulatory framework.

1.2.3. Equal treatment: Electronic fund transfers processed between accounts of the same financial institution or PSP must have identical characteristics for customers as transfers made between accounts of different financial institutions or PSPs, equating them to immediate transfers, 'Payment with Transfer', or batch transfers as applicable.

1.2.4. Competition among equals: Administrators of electronic fund transfer schemes shall not compete with participants in their own schemes. Instead, competition is expected among administrators of different electronic fund transfer schemes to attract new participants.

1.2.5. Price transparency: Prices defined by the administrators of each payment scheme shall be applied equally and without discrimination to all their participants. Furthermore, these prices must be reported to participants separately for each of the functions they remunerate within the scheme and shall not allow discounts, especially for prices offered by administrators who perform more than one function.

1.2.6. Open ecosystem: Each immediate transfer scheme shall interoperate with the rest of the immediate transfer schemes when this is necessary for its participants to originate transfers destined to any other receiving entity that is not a participant, under the same conditions applicable when a transfer is resolved within the scheme itself.

1.3. Functions of Electronic Fund Transfer Schemes.

1.3.1. The set of functions that an electronic fund transfer scheme may require to operate properly is detailed below. Unless otherwise stated, each payment scheme administrator shall define which participants may assume each function.

1.3.2. Administration, with prior authorization from the BCRA. Establish the operational, technical, and commercial rules of the payment scheme, ensure their compliance in accordance with the regulatory framework. Establish contractual relationships with each of the participants in the payment scheme.

1.3.3. Account Provision, only for financial institutions or Payment Service Providers that offer payment accounts. Provide freely available accounts to send and receive electronic fund transfers.

1.3.4. Authorization. Approve or deny a valid payment instruction sent by a client initiator to an originating entity or Payment Service Provider that offers payment accounts, based on criteria such as the availability of sufficient balances or suspicion of fraud.

1.3.5. Origination, only for financial institutions. Send an electronic fund transfer to a receiving entity through the operator and receive messages from the receiving entity, debiting funds when appropriate.

1.3.6. Operation or Processing. Route or switch electronic payment instructions between originating and receiving entities, ensuring the correct receipt of messages by all participants in a transaction.

1.3.7. Reception, only for financial institutions. Receive an electronic fund transfer from an originating entity and send confirmation or rejection messages, crediting funds in a timely manner and notifying their client.

1.3.8. Clearing. Establish the final positions -debtors and creditors- of the participating financial institutions within the established timeframes to allow settlement. Monitor the guarantees established by participants.

1.3.9. Settlement, only for Electronic Clearing Chambers authorized by the BCRA. Execute the payment of net balances by debtor entities to creditor entities as a result of the clearing process. Use the guarantees established by participants if necessary.

1.3.10. Initiation. Send a valid payment instruction at the request of a client initiator to the entity or PSP providing the client's account, capturing credentials through methods such as magnetic stripe, near-field communication, QR codes, user passwords, or others.

1.3.11. Transfer, only for financial institutions or Payment Service Providers that offer payment accounts. Credit funds to a receiving client's account when the account credited by the receiving entity is not in the name of that same receiving client, sending confirmation messages to the receiving entity and the client.

1.3.12. Acceptance. Maintain a contractual relationship with receiving clients of payments with transfers as a result of their organized commercial activity and ensure that operations are initiated and/or credited according to the scheme's rules, and can be confirmed and/or reconciled, charging commissions for these services and expanding the acceptance network.

1.4. Participants and Clients of Electronic Fund Transfer Schemes.

1.4.1. Client Initiator: Holder of the demand deposit account or payment account from which debits for transfers sent through the system will be made.

1.4.2. Client Beneficiary: Holder of the demand deposit account or payment account to which credits for transfers sent through the system will be made.

1.4.3. Originating Entity: Financial institution that sends valid payment instructions to receiving entities through the operator and receives messages from the receiving entity, debiting funds when appropriate.

1.4.4. Receiving Entity: Financial institution that receives valid payment instructions and sends confirmation or rejection messages for the instruction, crediting funds when appropriate.

1.4.5. Electronic Clearing Chamber (CEC): Institution, previously authorized by the BCRA, that administers the electronic clearing of operations for clients of financial institutions and other entities authorized by the BCRA.

1.4.6. Payment Service Provider (PSP): Legal entities that, without being financial institutions, perform at least one function declared in point 1.3. within an electronic fund transfer payment scheme.

1.5. General Responsibilities of Participants.

1.5.1. Originating and/or Receiving Entity:

1.5.1.1. Comply with the establishment of guarantees and maintain them within appropriate parameters.

1.5.1.2. Make electronic fund transfer services available to all their clients.

1.5.1.3. Assume full responsibility for the proper handling of electronic fund transfers they originate and/or receive, including the keeping of electronic records.

1.5.1.4. Ensure that electronic fund transfers and 'Payments with Transfer' processed between accounts of the same financial institution have identical characteristics for customers as transfers made between accounts of different entities, equating them to immediate or batch transfers as applicable.

1.5.2. Electronic Clearing Chamber:

1.5.2.1. Ensure the proper functioning of established guarantees and/or their settlement for each electronic fund transfer scheme in which they participate.

1.5.2.2. To the extent that CECs expand their operations beyond their specific clearing and settlement functions, they must comply with the regulations for each function as PSPs.

1.5.3. Payment Service Provider (PSP):
Comply with the norms and provisions of the administrator that regulate each of the functions they develop within an electronic fund transfer payment scheme, as declared in point 1.3.

1.5.4. PSP offering payment accounts:

1.5.4.1. Make electronic fund transfer services available to all their clients.

1.5.4.2. Assume full responsibility for the proper handling of electronic fund transfers they initiate and/or transfer, including the keeping of electronic records.

1.5.4.3. Ensure that electronic fund transfers and 'Payments with Transfer' processed between accounts of the same PSP have identical characteristics for customers as transfers made between accounts of different PSPs, equating them to immediate or batch transfers as applicable.

1.5.5. Administrator of an electronic fund transfer scheme:

1.5.5.1. Define the commercial, technical, and/or operational rules of the immediate transfer scheme they administer, and ensure they are adequate to the current legal and regulatory framework. Establish contractual relationships with each participant, through the signing of agreements that fix the obligation of these to comply with the scheme's rules, establishing fines and sanctions in case of non-compliance.

1.5.5.2. Refrain from competing with participants of their own schemes when the administrator additionally assumes, beyond the typical functions of operation, authorization, and/or clearing, functions that are also performed by their participants such as the acceptance function.

1.5.5.3. Ensure that prices offered to participants of the same payment scheme are the same for all those designated by these norms as equal, considering the exceptions provided in point 6.5, and that these prices are reported separately for each of the functions they remunerate within the scheme, without allowing discounts.

1.5.5.4. Ensure that their payment scheme interoperates with the rest of the immediate transfer schemes when this is necessary for its participants to originate transfers destined to any other financial entity that is not a participant, under the same conditions applicable when a transfer is resolved within the scheme itself.

1.5.5.5. Define what type of participants may assume each function, which is not expressly determined in these regulations.

1.5.5.6. Communicate with all their participants equally through standardized and numbered circulars when it comes to information that must be known without discrimination and simultaneously for all of them.

1.5.5.7. Ensure that messages between participants preserve the information of client initiators and beneficiaries and when payment accounts and/or demand deposit accounts are used.

1.5.5.8. Suspend preventively, as determined by the BCRA Board, any procedure, operation, and/or commercial rule of the payment scheme under their administration in situations where the stability, security, and/or efficiency for electronic fund transfers are seriously compromised.

1.5.6. Acceptor of an electronic fund transfer scheme:

1.5.6.1. Comply with the norms and provisions of the administrator to carry out the acceptance function within the payment scheme.

1.5.6.2. Maintain a contractual relationship with receiving clients of payments with transfers as a result of their organized commercial activity, being responsible for ensuring that operations are initiated and/or credited according to the scheme's rules.

1.5.6.3. Do not discriminate in the treatment of 'Payments with Transfer' based on the account provider.

1.5.6.4. Refrain from receiving payments on their own behalf, respecting the requirement to be a third party between the client initiator and the client beneficiary.

1.6. Supervision.

1.6.1. Participants in electronic fund transfer schemes must adhere to the supervision mechanisms that the BCRA determines for each type of participant, including real-time monitoring mechanisms.

1.6.2. Administrators of electronic fund transfer schemes must submit to the BCRA the documentation containing all the rules and obligations to which the payment schemes they administer are subject, all their updates, as well as copies of all circulars and technical documents sent to their participants simultaneously with the notification of the scheme participants.

Section 2. Immediate Transfers.

Complementary Characteristics.

2.1. Immediate transfer schemes shall operate under the deferred net settlement modality with real-time guarantee monitoring (RTGM), in order to eliminate intraday credit risk.

2.2. Real-Time Guarantee Monitoring (RTGM): For the authorization of each immediate transfer, the availability of sufficient guarantee funds must be verified in real time, so that it is not possible for an originating entity to draw beyond its constituted guarantee at any time. This real-time guarantee monitoring service shall be provided for each payment scheme by a CEC and shall centrally consider the operation of all payment instruments operating under the RTGM modality.

2.3. Security measures to order immediate transfers shall not require the geographic displacement of the client initiator and must be resolvable entirely remotely.

2.4. Active account inquiry services made available in a payment scheme shall be updated in real time and be available to other immediate transfer schemes when the potential receiving entity is not a participant of the same scheme as the initiating entity. They shall contain the following information at a minimum:

2.4.1. Account Holders

2.4.2. Uniform Banking Key (CBU), Uniform Virtual Key (CVU), and Alias

2.4.3. Currency

2.4.4. CUIT, CUIL, CDI, or others

2.4.5. Judicial Use Account

2.5. Confirmation Messaging: Once an entity receives an immediate transfer from an originating entity, the receiving entity must send a message to the originating entity confirming its credit or informing of its rejection, and this situation must be immediately notified to the client initiator.

2.6. Fraud Mitigation Tools: Each immediate transfer scheme shall have fraud mitigation tools that allow identifying suspicious patterns and alerting users before or after the authorization of the transaction. When a transfer is denied at the time of authorization for this reason, the user must be informed that it is due to suspicion of fraud.

2.7. Each immediate transfer shall have a unique standardized identifier among the multiple payment schemes, in accordance with Sections 3 and 4.

2.8. All interfaces of financial institutions and PSPs that display CBU or CVU data to their clients must also display the respective Aliases.

2.9. Valid Reasons for Rejection: A receiving entity may only reject an immediate transfer if there has been a failure in the update of the account database such that an account that was registered as enabled at the time of authorizing the transaction on the originating side could not receive the credit from the receiving entity. Administrators of immediate transfer schemes shall determine fines in their contracts for these failures. For operations in foreign currency, the valid reasons for rejection detailed in Section 6 shall also apply.

Section 3. Immediate Transfers: Payment with Transfer, Payment Request, and Withdrawals.

3.1. General Considerations.

3.1.1. Immediate transfers can be used to make payments either in person or remotely. This section presents the operation of 'Payment with Transfer', which refers to a procedure for the use case of payments in commerce where the initiation and acceptance functions can be used as defined in point 1.3. 'Payment with Transfer' must be implemented by all immediate transfer schemes.

3.1.2. 'Payment with Transfer' has two coexisting modalities: initiated by the acceptor and payment request. Initiation by the acceptor requires the capture of client initiator credentials to form the payment instruction, while the payment request requires the account identifier of the initiator and then a process of confirmation and sending of the payment instruction that is resolved on the side of the financial institution or PSP to which that account belongs, with the credentials they define.

3.1.3. These operations will be reflected in the account movements of client initiators and beneficiaries in accordance with Section 3 of the SNP Transfers regulations.

3.1.4. Acceptors must make available to merchants a return tool through a new reverse immediate transfer.

3.2. Payment with Transfer, Initiation by the Acceptor.

3.2.1. Financial institutions or PSPs that perform the acceptance function may offer merchants the possibility to charge for their sales through 'Payment with Transfer' either in person or remotely, enabling tools to allow the capture of client credentials that enable the initiation of 'Payments with Transfer' and to facilitate the confirmation and reconciliation of these payments.

3.2.2. The credentials for the initiation of a 'Payment with Transfer' by an acceptor must be the following:

3.2.2.1. Those of issued cards associated with the demand deposit or payment accounts of origin, for in-person capture, either through magnetic stripe, integrated circuit, or near-field communication.

3.2.2.2. Those of the Standardized Payment Interface (IEP), for in-person or remote operations, as defined in Section 4.

3.2.3. Additionally, each immediate transfer scheme may define other valid credentials for the initiation of 'Payments with Transfer'.

3.2.4. QR codes made available by acceptors to clients, in person or remotely, must allow ordering 'Payments with Transfer' in accordance with the standards established for the IEP in Section 4. When 'Payment with Transfer' is executed from the information obtained by invoking this

consultation method, the rules of the following point 3.3. will apply, since there would be no initiation by the acceptor, but a passive payment request. These QR codes must be governed by the standards defined by the BCRA.

3.2.5. All financial entities and PSPs that offer payment accounts must be able to authorize payment instructions received from third parties under the same conditions as for a 'Payment with transfer' ordered through their own interfaces.

3.2.6. All financial entities and PSPs that offer their customers the possibility of reading QR codes must adapt their systems to enable the reading of QR codes associated with any passive payment request, without discrimination, in accordance with the specifications of these regulations.

3.2.7. When merchants accept 'Payment with transfer', the choice of this payment instrument must be made by the paying customer themselves, through an explicit action, when the credentials used are shared by more than one payment instrument, whatever it may be. Printed and electronic receipts of a 'Payment with transfer' must clearly reflect the option for this payment instrument, both for the ordering customer and for the merchant. Administrators of immediate transfer schemes must ensure that acceptors participating in their schemes comply with these requirements.

3.2.8. When the credentials used to make a 'Payment with transfer' are also used by other payment instruments, such as in the case of debit cards, neither the administrators of such instruments nor their participants may set or impose prices, discounts, or arrange any operational and/or informational mechanism of any kind, associated with the use of these credentials for 'Payment with transfer' and/or their transactions.

3.2.9. Acceptors will charge commissions to merchants for their services, and an interchange rate will apply to these commissions to remunerate the originators and the providers of the ordering accounts, in accordance with what is established in Section 5.

3.2.10. Each immediate transfer scheme will establish the procedures for cases of disavowals by ordering customers of transfers initiated by acceptors, which will be the responsibility of the provider of the ordering customer's account.

3.3. Payment Request with Transfer.

3.3.1. Immediate transfer schemes will admit active and passive payment requests.

3.3.2. Active payment requests are issued by a potential receiving customer to an identifier of a specific account, such as an alias or a CBU/CVU, through the IEP as defined in Section 4. By accepting this payment request, the ordering customer sends a payment instruction to the entity providing their ordering account with the amount and destination account information contained in the request, as well as the identifiers that allow for tracking.

3.3.3. Passive payment requests are made available by an acceptor so that any potential ordering customer can consult them through the IEP, in accordance with Section 4. From the information obtained in the consultation, the ordering customer can send a payment instruction from the ordering entity side with the amount and destination account information obtained in the consultation, as well as the identifiers that allow for tracking. These passive payment requests must always have the option to be consulted through a QR code governed by the standards defined by the BCRA.

3.3.4. Payment requests can be used to make a 'Payment with transfer' to merchants in person or remotely, as well as for immediate transfers without commercial purposes in which an acceptor does not participate.

3.3.5. Acceptors will charge commissions to merchants for their services, and an interchange rate will apply to these commissions to remunerate the providers of the ordering accounts, in accordance with what is established in Section 5.

3.3.6. All financial entities and PSPs that offer payment accounts must be able to present to their customers the active payment requests they receive, as well as to send their associated payment orders.

3.3.7. Payment requests, both active and passive, may also be available to customers under the 'Paga el cliente ordenante' (The ordering customer pays) commercial model, detailed in Section 5.

3.4. Cash Withdrawals.

3.4.1. Immediate transfer schemes may be used so that ordering customers can withdraw cash from their accounts at merchants when an acceptor participates.

3.4.2. Initiations by the acceptor, as well as active and passive requests, will be admissible for cash withdrawals, in accordance with the specific definitions of the IEP in Section 4.

3.4.3. The commercial rules defined in Section 5 will apply to these transactions.

Section 4. Standardized Payment Interface (IEP).

Objectives and procedures.

4.1. The Standardized Payment Interface must establish the interoperability, messaging, and other information exchange procedures rules, such as application programming interfaces (APIs), common to all immediate transfer schemes.

4.2. The IEP must define, at a minimum, the following processes:

Standardized unique identification for each immediate transfer, even among multiple payment schemes
Initiation of immediate transfer with IEP credentials
Active payment request with transfer, including interaction with QR code
Passive payment request with transfer, including interaction with QR code
Information flows for the settlement and auditing of the interchange rates established in Sections 3. and 5.
Active account inquiry service

4.3. The IEP will adopt ISO 20022 standards as the general standard when applicable and in a gradual manner, after the first phase of implementation of these regulations in accordance with Section 7.

4.4. The definitions necessary for the implementation of the IEP, including the stages for the gradual adoption of the ISO 20022 standard, will be specified within the framework of the Interbank Commission for Payment Means of the Argentine Republic (CIMPRA), with the participation of all actors that the BCRA considers relevant, and will be implemented through the corresponding regulatory instruments.

4.5. In the event of discrepancies regarding the implementation criteria of the IEP, and the involved participants fail to reach an agreement, the BCRA will issue additional regulation to overcome the dispute.

Section 5. Electronic Funds Transfers, commercial rules.

5.1. General Definitions.

5.1.1. Electronic funds transfers must adequately remunerate each of the participants involved in each case. The prices and conditions of these remunerations will be determined by the rules of each payment scheme.

5.1.2. The prices to be paid by customers for electronic funds transfers may follow one of two different commercial models: the ordering customer pays the account provider, or the receiving customer pays the acceptor. When the receiving customer pays, an interchange rate will be implemented that delivers a part of the commission charged to the merchant to the provider of the ordering customer's account.

5.1.3. The 'Paga el cliente ordenante' (The ordering customer pays) commercial model is the one that generally governs electronic funds transfers, except for the 'Payment with transfer' described in section 3. When the 'Paga el cliente ordenante' model is used, prices cannot be defined as percentages of the transferred amounts.

5.1.4. In the 'Paga el cliente ordenante' model, transfers will be free for the ordering customer when they meet any of the following conditions:

5.1.4.1. Free initial Micro Tranche, for micro-enterprises in accordance with the conditions provided in the regulations on "Determination of the status of micro, small or medium-sized enterprise": when the transfers ordered by the customer do not exceed the amount defined in Section 6., cumulatively per calendar month, by currency, and by account provider.

5.1.4.2. The ordering customer and the receiving customer are the same person, natural or legal.

5.1.4.3. Transfers from or to demand accounts for judicial use.

5.1.4.4. The ordering customer has the status of "Financial Services User".

5.1.5. In the 'Paga el cliente receptor' (The receiving customer pays) model, transfers will be free for the receiving customer during the first three complete calendar months from the start of their operations, provided that the transfers received by the customer do not exceed the amount defined for this initial free tranche in Section 6., cumulatively per calendar month, by currency, and by acceptor. When these transfers are free, the interchange rate will not apply, nor will processing commissions be applied by the operator. This initial free tranche will only apply to receiving customers who meet the definition of "Small Businesses" established in point 6.3.1.

5.1.6. Batch transfers will allow the charging of commissions for geographic coverage between entities and to customers for the values agreed upon by the parties.

5.2. Payment with Transfer.

5.2.1. Acceptors may charge the merchants they serve up to the maximum price defined in point 6.3.1, whether for transfers initiated by the acceptor or with a payment request.

5.2.2. The commissions charged by the acceptor according to the preceding paragraph will imply the payment of the interchange rate established in point 6.3.1. in favor of the account provider, which will be settled in accordance with the operational procedures established by each scheme and in the IEP, detailed in Section 4.

5.2.3. Administrators of each immediate transfer scheme must ensure the uniformity of prices charged by participating acceptors of the scheme to each type of commercial activity, without allowing discounts, and may determine prices lower than the maximum price established in point 5.2.1. for each activity. The BCRA will exercise its supervisory functions by monitoring these prices lower than the maximums to safeguard the stability, efficiency, and security of immediate transfers.

5.2.4. Acceptors that also participate in other payment schemes other than immediate transfers must inform merchants of the price and conditions for accepting the 'Payment with transfer' payment instrument, separately and independently from the price and conditions of other payment instruments, in order to reflect the economic cost of each and avoid bundling and cross-subsidies between them.

5.3. Withdrawals.

Immediate transfers that correspond to cash withdrawals in accordance with point 3.4. will be subject to the 'paga el cliente ordenante' (the ordering customer pays) model, within the free conditions of the first tranche established in point 6.2.1. and therefore the interchange rate will not apply to them. Acceptors may remunerate and/or charge commissions associated with this service.

Section 6. Electronic Funds Transfers: operational variables, prices, and interchange rates.

6.1. Minimum Limits and Equivalences with Units of Purchasing Value (UVA).

6.1.1. Immediate transfers may be processed without the need for special requests up to an amount equivalent to 15,000 UVAs as a minimum for operations in pesos per day and per account (as established in point 6.1.2.), and for 12,500 US dollars or euros for operations denominated in these currencies, always per day and per account.

6.1.2. The approximate equivalent in pesos of the amounts expressed in UVAs in the present ordered text, as well as any modification to these parameters expressed in this section in UVAs, US dollars, or euros, will be published by the BCRA three times a year, in the months of March, July, and November.

6.2. Initial Free Tranche.

6.2.1. 'Paga el cliente ordenante': The accumulated amount of the initial tranche referred to in point 5.1.4.1. in which electronic funds transfers will be free for ordering customers is equivalent to 7,500 UVAs for operations in pesos, and to 6,000 US dollars or euros for operations in these currencies (as established in point 6.1.2), always cumulatively per calendar month, by currency, and by account provider.

6.2.2. 'Paga el cliente receptor': The accumulated amount of the initial tranche referred to in point 5.1.5. in which electronic funds transfers will be free for receiving customers is equivalent to 1,000 UVAs for operations in pesos, and to 1,000 US dollars or euros for operations in these currencies (as established in point 6.1.2.).

6.3. Payment with Transfer, prices, and interchange rates.

6.3.1. Acceptors may charge the merchants they serve a maximum of the price detailed in the table below, as a percentage of the amounts received by merchants through 'Payment with transfer', in accordance with Section 3. These commissions charged by the acceptor will imply the payment of an interchange rate in favor of the account provider. The table below establishes categories of merchants based on their revenue with 'Payment with transfer' (as established in point 6.1.2), and for each of these categories their maximum prices, interchange rates, as well as which participants must assume the payment of the transaction processing prices. This processing price must be the same for any transaction.

Category of commerce	Maximum revenue with payment with transfer per calendar month by category (mutually exclusive)	Maximum price to be paid by the merchant to the acceptor	Percentage on price charged by the acceptor to the merchant to be paid to the account provider as interchange rate	Percentage of the transaction processing price to be paid by the account provider	Percentage of the transaction processing price to be paid by the acceptor
Large Commerce	No limit	0.8 %	75 %	75 %	25 %
Medium Commerce	500,000 UVAs	0.8 %	50 %	50 %	50 %
Small Commerce	100,000 UVAs	0.8 %	25 %	25 %	75 %

6.3.2. For the initial classification of merchants by the acceptor for the purpose of determining the applicable interchange rate, the revenue of the previous calendar month with other debit card schemes must be taken into account; administrators must validate these initial classifications.

6.3.3. For the classification of merchants each calendar month by the acceptor for the purpose of determining the applicable interchange rate, the revenue of the previous calendar month through 'Payment with transfer' must be taken into account.

6.4. Valid Reasons for Rejection by the Receiving Entity for Foreign Currency Operations.

6.4.1. Suspicion that the transfer is associated with a breach of regulations on the purchase of foreign currency by resident natural persons for the formation of external assets.

6.4.2. In each case, the ordering customer must be informed of the reason for the rejection.

6.5. Participants in Electronic Funds Transfer Schemes with Special Character for Purposes of Their Treatment by Administrators.

National Social Security Administration.

Section 7. Adaptation and Implementation Deadlines.

7.1. Adaptation Plan.

Each of the entities authorized to function as administrators of electronic funds transfer schemes must present an adaptation plan to this regulation and obtain its approval by the General Sub-Department of Payment Means before the maximum validity date of the first phase of implementation detailed below. These adaptation plans must establish the implementation phases of these regulations with a deadline of November 29, 2021, from which date they will have full effect and each administrator must comply with all the provisions required herein. The use of card credentials associated with payment accounts for the initiation of a 'Payment with transfer' by an acceptor in accordance with point 3.2.2.1. may not begin before May 31, 2021. Administrators that, on the date of entry into force of this regulation, perform more than one of the functions that have been declared incompatible in accordance with 1.2.4. and 1.5.5.2. of this document, must inform in said plan the measures they will take to adapt their activity to the limitations established in said regulation.

7.2. Implementation Deadlines.

The first phase of implementation of this regulation must be completely operational by December 7, 2020 at the latest. In this first phase of implementation, it must be done at a minimum:

7.2.1. Enable customers of financial entities and PSPs that offer payment accounts to order and receive immediate transfers involving payment accounts, without distinction regarding the immediate transfer schemes involved, properly registering the information of the operation in accordance with what is provided in Section 3. of the regulations on "National Payments System - Transfers".

7.2.2. Enable customers of financial entities and PSPs that offer payment accounts to order and receive 'Payments with transfer' with debit cards in accordance with point 3.2.2.

7.2.3. Make available, by acceptors of 'Payments with transfer' that display QR codes, at least for a representative set of merchants that ensures the stability of the platforms in the initial stage, the basic information of the passive payment request defined in point 3.3.3., in such a way that payments with transfer received are treated on equal terms.

7.2.4. Adapt systems to enable the reading of QR codes associated with any passive payment request, for the case of financial entities and PSPs that offer their customers the alternative of reading QR codes, in accordance with what is provided in point 3.2.6.

7.2.5. Eliminate the conditional crediting of immediate transfers in pesos, for the case of 'Payment with transfer', applying only the criteria for rejections established in point 2.9.

7.2.6. Allow cash withdrawals at merchants selected by acceptors through immediate transfer schemes, as established in point 5.3.

7.2.7. Comply with what is established in Section 6, except for point 6.2.2.

-Index

Section 1. General Provisions.
1.1. Scope. Functional Approach.
1.2 Definitions.
1.3. Exclusions.
1.4. Functions.

Section 2. Payment Service Providers that offer payment accounts.
2.1. Registration in the Registry of Payment Service Providers that offer payment accounts.
2.2. Fund Administration.
2.3. Information Regime and Supervision.
2.4. Transparency.
2.5. Funds Transfers Sent From and Received in Payment Accounts.
2.6. Breaches and Sanctions.

B.C.R.A. Payment Service Providers
Annex III to
Com. "A"
7153

Section 1. General Provisions.
1.1. Scope. Functional Approach.
1.1.1. The figure of Payment Service Provider (PSP) aims to establish the same rules for legal entities that, without being financial entities, perform the same function in the provision of payment services, and therefore compete.
1.1.2. Under this functional approach, both financial entities and PSPs must observe the same rules for equal functions they develop in the provision of payment services within the framework of the National Payments System.
1.1.3. The National Payments System comprises all payment instruments regulated by the Central Bank of the Argentine Republic (BCRA), as well as financial market infrastructures and payment schemes necessary for their functioning. This definition covers both retail payments, which include fund transfers or high and low value payments, as well as wholesale payments between financial entities and with the Central Bank of the Argentine Republic (BCRA).
1.1.4. Each payment instrument legally and normatively defines a general standard for the realization of debits and credits between accounts.
1.1.5. Payment schemes are the set of operational, technical, and commercial rules that make possible the implementation of the general standard defined for each payment instrument when at least three parties are involved: an orderer, a receiver, and one or more financial entities or PSPs. Payment schemes define what functions each participant performs within the scheme. A payment instrument can have multiple competing payment schemes, such as is the case with credit cards. Each payment scheme must have an administrator that organizes it.
1.1.6. These regulations constitute the general framework of the regulation of each instrument. In the implementation of each payment scheme, specific rules necessary for its functioning may be established, including functions susceptible to being performed within a payment scheme.
1.1.7. Financial entities and PSPs may perform multiple functions within a payment scheme as long as these regulations on "Payment Service Providers" or those of each particular payment instrument do not expressly limit them.

1.2. Definitions.
1.2.1. Payment Service Providers (PSPs) are considered to be legal entities that, without being financial entities, perform at least one function within a retail payment scheme, within the global framework of the National Payments System.
1.2.2. Payment schemes are systems of commercial, technical, and/or operational rules that make possible the functioning of a payment instrument when at least three parties are involved: an orderer, a receiver, and one or more financial entities or PSPs.
1.2.3. The following will not be considered retail payment schemes for the purposes of this regulation:
1.2.3.1. Payment schemes regulated by the National Securities Commission (CNV) for primary placement and/or secondary negotiation, and/or the clearing and/or settlement of securities.

1.2.3.2. Payment schemes whose purpose is the retention and/or collection and settlement of sums intended to cancel tax or other obligations with the State at any of its levels and agencies.

1.2.4. Electronic Clearing Chambers may perform functions within a retail payment scheme, within the global framework of the National Payments System, on equal footing with financial entities and PSPs, in accordance with the specific regulations that already govern them and provided that it is not limited by the specific regulations of each payment instrument.

1.3. Exclusions.

The following may not operate as PSPs:

1.3.1. Legal entities that are not regularly constituted in the country, or, if they are private legal entities constituted abroad, have not complied with the requirements of Law 19.550 (General Companies Law) and its modifications for the habitual exercise in the Argentine Republic of acts included in their corporate purpose.

1.3.2. Legal entities that the regulations of the CNV (Comisión Nacional de Valores) expressly recognize as markets, clearing houses, or agents of any type.

1.3.3. Legal entities whose shareholders, voting rights, administration or oversight bodies are persons included in the provisions of items a), b), d), e) or f) of Article 10 of the Financial Entities Law, or that have been convicted of intentional crimes against property, public administration, the economic and financial order, or public faith; for violation of secrets and privacy, illegal association, or for infringement of Article 1 item b) of the Foreign Exchange Criminal Regime.

1.3.4. The provisions of the preceding point are exempted for shareholdings acquired in securities markets that do not reach the threshold of 20% of the capital or voting rights.

1.4. Functions.

The following are explicitly defined as some of the functions to be performed within a payment scheme:

1.4.1. Account Provision. Both financial entities and PSPs can offer the necessary accounts for the execution of debits and credits within the payment scheme. When accounts are offered by PSPs, they are called payment accounts.

Payment accounts are freely available accounts offered by PSPs to their clients to order and/or receive payments.

1.4.2. Administration. Establish the operational, technical, and commercial rules of the payment scheme, ensure their compliance in accordance with the regulatory framework, establishing contractual relationships with each of the participants in the payment scheme.

When the specific regulations of a payment instrument require authorization from the BCRA to fulfill the administration function, consideration will be given to the level of competition existing in the market, the efficiency and quality of service of existing administrators, systemic risk, and whether there is a clear willingness on the part of potential participants to contract with the administrator under analysis.

1.4.3. Acceptance. Maintain a contractual relationship with payment-receiving clients as a result of their organized commercial activity and ensure that operations are initiated and/or credited in accordance with the scheme's rules, and can be confirmed and/or reconciled, charging commissions for these services and expanding the acceptance network.

Section 2. Payment Service Providers that offer payment accounts.

2.1. Registration.

Payment Service Providers that offer payment accounts (PSPOCP) must register in the "Registry of Payment Service Providers that offer payment accounts" enabled by the Superintendence of Financial Entities and Currency (SEFyC).

To do so, they must access the website of the Federal Administration of Public Revenues (AFIP) at www.afip.gob.ar –using the tax key of the legal entity performing the registration– to process the username and password that will allow them to perform the registration electronically through the application enabled by the BCRA, attaching the documentation and integrating the information detailed below:

2.1.1. Copy of the articles of association or bylaws and all their modifications (in a file with ".pdf" format).

2.1.2. Data of the payment service provider.

LEGAL ENTITY NAME:

TRADE NAME OR BRAND:

UNIQUE TAX IDENTIFICATION KEY (CUIT):

LEGAL ADDRESS
§ Street and Number:
§ Locality:
§ Province:
§ Postal Code:
§ Telephone:
§ E-mail: this email address will be considered the only valid one for sending information and/or requests to the BCRA and receiving its notifications.

SPECIAL ADDRESS –the address where the pertinent operational processes will be carried out and the records associated with said operation will be kept must be stated–:
§ Street and Number:
§ Locality:
§ Province:
§ Postal Code:
§ Telephone:

LEGAL REPRESENTATIVE / ATTORNEY

§ First and Last Names:
§ Type and number of identity document:
§ E-mail:

DATA SECURITY OFFICER –designated for the purposes of accessing the computer environments of BCRA Internet sites–

§ First and Last Names:
§ Position:
§ Type and number of identity document:
§ E-mail:

OFFICER FOR OVERSIGHT OF PAYMENT SYSTEMS

§ First and Last Names:
§ Position:
§ Type and number of identity document:
§ E-mail:

OFFICER FOR INFORMATION REGIME

§ First and Last Names:
§ Position:
§ Type and number of identity document:
§ E-mail:

OPERATIONAL AND COMMERCIAL DESCRIPTION

§ Payment services to be provided and the payment instruments involved.
§ Payment accounts offered, including their specific terms and conditions, including the use of CVU (Virtual Unified Account).
§ Payment schemes in which they perform the function of administrator, including the declaration of all their participants.
§ Payment schemes in which they participate in a function other than that of administrator, specifying the functions assumed in each case.
§ Modes of fund restitution if required or if activity ceases.

IDENTIFICATION OF SHAREHOLDERS AND DIRECTORS

§ Identification of natural persons who hold at least 20% of the capital and/or votes of the legal entity or who by other means exercise final control, direct or indirect, of the PSP (main members of the governing body). § Regarding each of the above, and those who make up the administration or oversight body: their personal data and sworn statement made by each of them declaring that they are not included in any of the situations described in point 1.3.3.

2.1.3. Sworn declaration that all information presented electronically is true, that the attached documentation is a faithful copy and that the originals are available to the SEFyC, indicating the location where they are kept.

Upon completion of the registration application process, they will electronically receive a confirmation of the start of the procedure.

If deficiencies, inconsistencies, or lack of compliance with some of the points of the regulation are detected in the submission, these will be communicated to the applicant within 10 business days of the request.

Applicants must correct the submission by meeting the regulatory requirements, under penalty of having the procedure deemed abandoned and considering the PSPOCP as an entity not registered in the "Registry of Payment Service Providers that offer payment accounts".

Once the requirements are deemed satisfied, the SEFyC will issue a registration certificate and grant the applicant a number in the "Registry of Payment Service Providers that offer payment accounts".

Any change registered in the information required in this Section must be reported to the SEFyC within 15 business days of occurring through the corresponding application.

2.2. Fund Administration.

2.2.1. The funds of clients credited in payment accounts offered by PSPOCP must be available at all times –immediately upon request by the client– for an amount at least equivalent to that which was credited in the payment account. To this effect, the systems implemented by the PSPOCP must be able to identify and individualize the funds of each client.

2.2.2. 100% of client funds must be deposited –at all times– in sight accounts in pesos in financial entities in the country. Without prejudice to this, upon express request by the client, balances credited in payment accounts may be transferred for application to the execution of operations with "money market funds" in the country, and the payment account must be debited. In the latter case, it will be required that the invested balances be reported separately from the rest.

2.2.3. For the execution of transactions on their own account (payment of suppliers, payment of salaries, etc.), PSPOCPs must use a "operational" sight account (freely available) distinct from the account where client funds are deposited.

2.3. Information Regime and Oversight.

2.3.1. PSPOCPs must:

2.3.1.1. Comply with the information regime that is established.

2.3.1.2. Grant access to their facilities and documentation to the personnel designated by the SEFyC for this purpose and make available to the BCRA the real-time consultation and reporting tools that the General Sub-Department of Payment Means determines for each type of provider and according to their volume of operations.

2.4. Transparency.

Advertising carried out through any medium and documentation issued by PSPOCPs must include a clear and express mention that:

2.4.1. They are limited to offering payment services and are not authorized to operate as financial entities by the BCRA.

2.4.2. Funds deposited in payment accounts do not constitute deposits in a financial entity, nor do they enjoy any of the guarantees that such deposits may have according to the legislation and regulations applicable in matters of deposits in financial entities.

2.5. Transfer of funds sent and received in payment accounts.

PSPOCPs must comply with the obligations established in the regulations on "National Payments System. Transfers" and "National Payments System – Transfers – Complementary Regulations".

2.6. Non-compliance and Sanctions.

PSPOCPs and the members of their governing, administration, and oversight bodies, for non-compliance with the regulations issued by the BCRA to regulate their activity, will be subject to the application of sanctions as provided for in Articles 41 and 42 of the Financial Entities Law and concordant provisions.

Circular SINAP 1-116: Payment Service Providers. National Payments System - Transfers. National Payments System - Mobile Payments Platform (PPM). Adjustments

Similar documents from other regulators