Batching and Clearing Files

Batching is how the acquirer collects captured transactions and prepares them for clearing. At agreed cut off times, usually once a day, the acquirer groups all the transactions it has received from its merchants into clearing files, organised by scheme and by issuer. Each file contains the full details of every transaction, including the card number, the amount, the merchant, the date and the authorisation code that links the clearing record back to the original authorisation. The acquirer sends these files to the scheme, which validates them and sorts them for delivery to each issuer. The scheme plays a central role in clearing. It checks each file for errors, such as missing fields, duplicate transactions or amounts that do not match the authorisation. It converts currencies where needed, for example when a customer uses a card issued in one country to pay a merchant in another. It calculates the totals that each issuer owes and each acquirer is owed, and it prepares settlement reports. The scheme's clearing system is a high volume operation, processing billions of transactions a year, and its accuracy is critical, because an error in clearing can mean an issuer is charged for a transaction that never happened. Clearing files use standard formats defined by each scheme, and the details matter enormously in implementation work. A business analyst working on a clearing interface needs to understand the file layout, the field definitions, the validation rules and the error handling procedures. They also need to understand the clearing cycle, including cut off times, the treatment of late files, and the process for correcting errors. A file that misses its cut off may be held to the next cycle, which delays settlement to the merchant and can affect the merchant's cash flow, so timing is a real operational concern. Follow one clearing file through the night. An acquirer batches 8,400 transactions worth Rs 6.2 crore from its merchants at the 10 in the evening cut off and sends the clearing file to the scheme. The scheme validates the file and rejects two records, because their amounts do not match the original authorisations. The acquirer corrects the two records and resubmits, but the corrected file misses the scheme's processing window, so settlement to those two merchants is delayed by a day. A second file arrives at ten forty in the evening, forty minutes after the cut off, and is held for the next cycle entirely, which delays settlement for all of its merchants by a day and affects their cash flow. The file format, the validation rules, and the cut off time are not back office details. They decide when merchants get paid. An analyst working on a clearing interface needs to document the file layout field by field, the validation rules and the error codes, the cut off times, and the procedure for correcting and resubmitting a failed file. The test pack should include a file with a duplicate transaction, a file with an amount that does not match its authorisation, a file that arrives after cut off, and a file with a missing mandatory field. Each test should assert the error message, the handling, and the effect on merchant settlement timing, because a file that fails silently is worse than a file that fails loudly. The operations runbook should name who is called when a file fails after hours, since clearing files do not respect office hours.