We will talk in this post about the after-transactions operations. These are mainly three operations that happen usually in a batch mode, daily or multiple times through the day:
- Clearing
- Settlement
- Reconciliation
Settlement and Reconciliation Files
Clearing is the process of marking the transaction as final, and to calculate the net amounts to be transferred between the different parties in the transaction, to be used for settlement later, which is the actual money movement between these parties.
Reconciliation is the process where any party in the transaction compares the transaction books, logs, and ledgers that they have with the books from the other party. The exchange of settlement and reconciliation files between the different parties is quite important to do the needed reconciliation and to make sure that the books are matching.
Settlement is the process to move the net money amounts between the different parties through this chain, starting from the account holder to end at the merchant bank account. Through all these steps, many fees are deducted, for the issuer bank, the card network, and the acquirer. Every facilitator as well has different fees structure for the merchants including some other amounts like the monthly costs of terminals lease for example.
In the below diagram, the exchanged clearing and settlement files are shown:
Files 1 and 2
Not all transactions are completed once they are authorized. Especially for transactions that are not PIN-based. The terminal first sends an authorization message to authorize and approve the transaction and holds the transaction amount in the cardholder account. At end of the day, all these transactions are captured in a batch.
In a restaurant, for example, a small amount of tip can be added to the transaction before it is captured. That is how for swipe cards, you can add the tip to the receipt. This will be added to the total amount at end of the day by the restaurant when the transaction is captured.
For Card Not Present operations (CNP), some e-commerce merchants just authorize the transaction when the purchase is done by the cardholder, but only capture or clear it when the goods are shipped.
These are called DMS or (Double Message System) transactions. PIN operations are always SMS (or Single Message System) transactions, and they are cheaper in terms of fees for the merchant.
With the terminal, a command is called to request to capture all the authorized transactions as a batch. Some terminals do this through an “End of Day Report” command, which submits a file of all transactions to be captured. This file is called a "Base II" file as well.
Indeed these batch files are submitted to either the facilitator (1) or the acquirer processor (2).
Files 3, 4, and 5
This is where the merchants reconcile their books that they have in their accounting or order management or billing system, with the files that they get from the facilitator or the acquirer processor.
If we go back to Adyen as an example, we can see that there are multiple files being transferred on daily basis. The integration here is by one of two methods:
- Adyen exposing an HTTPS URL to download the files from, as explained on this page.
- Adyen exposing an SFTP server, where the merchant can automatically download the needed files from.
File 6
These are the files released by the card network itself about the transaction information. The famous ones are:
- File T140 from Mastercard
- File EP7474 from Visa
Other files for different purposes, like chargebacks, are sent to the acquirer or acquirer processor.
File 7
These are files created by the issuer processor or the issuer bank that contain information on fraudulent transactions. When cardholders call the issuer bank to report transactions that they see as fraudulent, this file is created and sent to the card network to be investigated with the acquirer and the merchants. These files are called:
- SAFE for Mastercard
- TC40 for Visa
File 8
This is issued by the issuer processor for the issuer bank reporting the daily transactions. For example for Marqeta, the issuer bank is the one who needs to expose an SFTP server so Marqeta can upload the files on it daily.
There are HTTPS endpoints exposed by Marqeta as well so the bank can download whatever settlement reports are needed.
The integration for all these files is quite simple, based on simple SFTP files copy or GET URL. A service like AWS Transfer for SFTP can be of good use as a managed SFTP server that abstracts an S3 bucket. If you are the issuer bank for example, using the files uploaded on S3 using the SFTP service, you can ingest these files later in any other reconciliation application or analytics data lake.
A lot of commercial off-the-shelf products can do the reconciliation operations, especially for the standard files from the card networks.
Moving the Real Money
It starts with the issuer bank transferring the settled amount to the card network while deducting any fees (like interchange fees for example). Usually, card networks when they operate in a country they will have an account for settlement in a local bank. Settlements from issuer banks shall be transferred to this account.
The issuer bank is the one that is liable in front of the card network. So the issuer bank has to pay to the card network even if the cardholder account doesn't have enough credit. And that is why step 2 doesn’t have to always happen before step 1.
ACH
Any transfers between banks in the same country are usually done using ACH. Which is more a country-wide messaging and accounting system, with all financial institutions as members, that records that Bank A will receive net amount X from Bank B.
Based on these messages and records, the real money movement is done on the net amounts between these banks’ accounts at the country’s central bank.
The card network then transfers to the acquirer bank the settled amount minus any fees, This is using the acquirer bank account at the settlement bank.
The acquirer bank keeps an account or a ledger of all the amounts it received (or shall receive) from the card network. Then it transfers directly to the merchant bank account. If there is an aggregator in the middle, all the amounts for all the merchants for this aggregator are transferred to the aggregator account. That is why if merchants are using an aggregator, they will get their payouts one or two days later than if they are dealing with an acquirer directly.
By this post, we have somehow covered the basics. In the following posts, we will cover some interesting topics like tap-to-pay, ISO20022, Apple and Google Pay, and others.