The Split CNAB240 is a product that does massive payments by perfmorming P2P transfers and TEDs (Bank Transfers OUT) from a single input file in a customized CNAB240 layout. Click here to see the more details about the customized layout.
The settlement process is done in the steps below:
1) The sub-issuer (SE) or its acquirer performs a cash-in (value entry via CIP, TED or payment slip) on the SE's stock banking account:
What is an Acquirer?
Acquirers are companies that affiliate, accredit merchants and service providers for the acceptance of cards as a means of payment.
2) The SE's acquirer, or the SE itself, sends the transactional file (
.txt format), containing the information about the transactions that will be performed, to our cloud storage via SFTP.
/input: It is where the SE inputs the sending file that will be used to split the payment;
/error: It is where the application inputs the error return file when confirmed any error;
/output: It is where the application inputs the sending file to start processing (this directory is used as the history of valid sending files used for successful transactions);
/result: It is where the application inputs the return file after processing the transactional file.
3) The application will validate the file, read the data and split the amount through the defined accounts (either bank accounts or payment accounts).
For the operation to succeed it is required that the amount is in the SE's stock banking account.
The returned files will follow the nomenclatures below:
- RET_OriginalFileName.txt: When the returned file is generated by a processed or scheduled file;
- ERR_OriginalFileName.txt: When the returned file is sent to the
- RET_OriginalFileName_sequential.txt: When the returned file is generated by a schedule. The sequential number at the end of the file name is used to identify the scheduled transaction that was processed.
Our partners can provide us the CNAB240 file at any time by sending it via STFP to our cloud storage, from there the processing is initiated in the following steps:
1) It is checked if the file is doubled or not. If it is doubled, it goes to the
2) It is checked if the origin account does exist. Otherwise it goes to the
3) It is checked if the file is in the defined layout. Otherwise, the file is moved to the
4) It is checked if there are repeated lines in the file. If there are repeated lines, the file is moved to the
5) The date of the transactions is checked. If all transactions are dated before the current date, the file is moved to the
/error directory. If some of the transactions (not all) are dated before the current date, the file is still processed and moved to the
/result directory, however all transactions dated before the current date will have an error status in the return file.
6) The balance in account versus the amount required to make all transfers is checked:
- If it is a file with no scheduling transactions and the balance is not greater than the required amount, the file is moved to the
- If it is a file with a transactional amount equal to BRL 0, the file is moved to the
7) If no errors are found after, the file is sent to the
/output directory and the processing is started.
During the processing, to perform P2P transfers, the system tries to itentify an unique combination of:
- Bank code + Bank branch + Beneficiary account
Respecting the pre-defined layout, such combination should be informed in the segment/lot positions:
- Bank code: position 21 to 23;
- Bank branch + Beneficiary accout: position 24 to 43.
If this combination is equal to the agreed with the SE (SE's stock banking account), the system searches for the account identification code of the beneficiary (
id_conta) and performs a P2P Transfer of the amount informed in the transactional file.
Just as the sending file is in the CNAB240 layout, the file returned to the SE will also be available in a CNAB240 layout.
Thus, every 30 minutes, the system schedules a return file generation to the SE, containing the return of each transfer performed a return to SE file generation schedule containing the return of each transfer made in the file used. If any transfer is still unreturned, the processing of the return file stays pending and is executed again in the next processing window.
Return codes for P2P transfers are:
- Success: "00";
- Rejection: "H4" (return code for situations where there is no account in the base of the SE for the CPF/CNPJ informed or when there is a failure in transmission).
Return codes for TED transfers:
- Success: "00";
- Rejection: Occurrence/Return code returned by the bank in question (e.g., "H4", "RJ", "AN").
Click here to see all codes returned in our CNAB240 file.
To schedule a P2P transfer, the system tries to validate the combination for the P2P transfer and then the date field. Respecting the predefined layout, the settlement date must be informed in the following segment/lot positions 94 to 101.
If this date is equal to D+0, the transaction is settled in the day. If the date is higher than D+0, the transaction is scheduled to be performed on the informed date.
There will be no balance or debit validation at the time of scheduling. The balance will be validated and debited from the account at the time of settlement. Scheduled transactions will process at 06:00 (GMT-3) on the related date.
The business requirements are:
- CNAB240 model at DOCK's layout;
- Only one
id_contaper CPF/CNPJ in the SE's database. If there is more than one account, the amount of the split will be credited on the oldest active account;
- A bank account that will be the trigger for the P2P tranfers;
- Only one account to debit the transfer amounts.
The only technical requirement to use Split CNAB240 is a connection via SFTP protocol.
Updated 3 months ago