Clearing, settlement and reconciliation
Clearing
Clearing is the process of exchanging clearing data.
This term denotes the sharing of files between parties according to specific cutoff times.
In an acquirer's dual message setup, a merchant uploads a file containing all transactions completed by the end of the day. The switch or acquirer then gathers these uploaded batches from merchants and forwards the files to schemes (such as Mastercard, Visa, Diners, etc.), requesting funds for the services provided.
Clearing data includes, for example, transactions from the acquirer to the issuer to confirm completed purchases (also known as "presentments"). The card scheme clearing system accepts the data, edits it, computes, applies the appropriate fees, and then routes it to the appropriate recipient. The clearing messages contain data but do not actually exchange or transfer funds.
Clearing transaction flow - usually within one day
The <<glossary:FAST>> message of a clearing sub-transaction adopts a similar principle to the authorization message. This means that the bank gets a preserved representation of the original ISO message information provided by the card scheme with no loss of detail.
The benefits are:
- improved granularity on interchange data
- improved granularity on card scheme fees
- improved granularity on presentment data.
The <<glossary:FAST>> Interface facilitates the transmission of clearing transactions in the below steps:
| Step | Description |
|---|---|
| 1 | Paymentology receives the presentment file from the relevant card scheme |
| 2 | Paymentology matches the presentment data to preceding authorization. A unique reference is given to the presentment to assist in relating the presentment to the original authorization. |
| 3 | Paymentology routes the FAST presentment data to the client |
| 4 | No response is required from the client for presentment messages that are transmitted. |
Card scheme clearing file structure
The principal file that is delivered to Paymentology in accordance with the relevant card scheme clearing timings is in the Integrated Product Messages (IPM) format, which is based on the ISO* 8583-1993 standard and has the following characteristics:
- Variable length: an element in the message or the entire message can have adifferent length based on the data it contains.
- Variable format: the location of an element within a message can varybetween messages, depending on the other elements that are present in each message.
- Bitmap orientation: the bitmap indicates whether data elements are present orabsent from the message.
IPMs contain four types of message elements:
- Message Type Identifier (MTI): identifies the purpose of the message, such as Administrative, Chargeback etc.
The four generic MTI-types are:
| MTI | Description |
|---|---|
| 1240 | Presentment |
| 1442 | Chargeback |
| 1644 | Administrative |
| 1740 | Fee Collection |
- Two bit-maps: a series of binary digits (bits) that indicate the presence or absence of data elements.
- Data elements: message elements, defined within the ISO 8583-1993 specification, that may contain data.
- Private data sub-elements: message elements that the card scheme define to support data not defined within the ISO 8583-1993 specification.
The MTI and one other field (DE24) within the ISO structure fully define the message type.
Full in-depth coverage of all message types is provided in the card schemes' reference manuals.
Each card scheme produces clearing data files in accordance with their own timetable.
Paymentology clearing file import process
Paymentology commences the import process within 3 minutes of confirming receipt of the clearing file. The import process varies depending on the volume of presentment data within the file, but typically the entire import process is completed within 10 minutes.
The import process includes the following steps:
- Read in the content of the presentment message and split ISO messages into component form
- Perform matching process to link presentment data to authorizations
- Prepare XML/CSV file feeds for scheduled onward transmission to the bank
Matching presentment to authorization
Card schemes do not provide any unique field which links a presentment back to a preceding authorization, but in more than 99%* of cases Paymentology can utilise several fields to create this link.
Principal fields used to link a presentment to a preceding authorization are:
DE38: The authorization code created by Paymentology at time of authorization. This is the authorization code that customers see printed on their receipts following a spendDE2: The card number involved in the transaction ()DE42: The merchant IDDE4: The local spend amount.
Secondary fields used to link a presentment to a preceding authorization are:
- Authorization/Settlement
DE63: Transaction Life Cycle IDDE42: Card Acceptor ID CodeDE37: Date and Time, Local Transaction
- Authorization
DE7: Transmission Date and Time
- Settlement
DE12: Date and Time, Local Transaction
Learn more about
<<glossary:Banking.Live>>'s matching process in TID and RID and Mapping TID and RID.
*The process of matching presentment to authorization can be complex and typically involves five or six steps to achieve optimal matching. Note that in outlier cases a match can never be found, such as:
- where a retailer forced a presentment when an authorization never happened
- where a retailer manually keyed in a presentment because perhaps the card machine was not working at the authorization time
- where amounts and retailer details differed at the presentment stage for some reason.
Clearing data identification
Paymentology provides clearing data in distinct formats tailored for different payment networks. The following excerpts will provide clarity on the main differences among the data payloads.
For more information about the payloads, please refer to the
<<glossary:FAST>>clearing and settlement payload here.
For Mastercard
{
"MESSAGE_TYPE": {
"Message_Type": "1240",
"Message_Desc": "Presentment"
},
"SUMMARY": {
"TID": "2224644632345000077",
"RID": "2312765",
"PID": "1267",
"ClientID": "278213",
"Network": "MC",
....
},
"ISO_MSG": {
"2": "182780976",
"3": "000000",
"4": "000000001200",
...
}
}For Visa
{
"PacketType": "TC05",
"Header": {
"DE2": "178630044",
"source": "V",
"rid_set": "2131000022",
"rid_auth": "258661",
...
},
"iso_msg": {
"tcr_0": {
"Account Number": 178630044,
"Account Number Extension": "000",
...
},
"tcr_1": {
"Business Format Code": " ",
"Token Assurance Level": " ",
...
}
}
}Settlement
Settlement is the process that facilitates the movement of funds between issuers and acquirers.
The funds represent the net equivalent of monetary value from clearing processing. These funds are exchanged each day with the respective card scheme and their customers for the net monetary value of the cleared transactions.
When acquirers and issuers are onboarded by schemes, they establish accounts with correspondent banks for fund settlement.
For domestic transactions, accounts are arranged with central banks, while for international transactions, accounts are set up with selected USD distributors acting as correspondent banks, often City Bank or HSBC.
The card scheme calculates the net position of each of its customers (in the reconciliation currency) and performs the following settlement functions:
- Sending advisements
- Transferring funds (when applicable)
Settlement cycles
Card schemes perform settlement activities from Monday through Friday following the standard clearing cycle schedule.
<<glossary:Banking.Live>> clients receive settlement advisements from the card scheme via Paymentology. Transactions processed in the Saturday clearing cycles are included in the Monday net settlement totals so advisements that clients receive on Monday report both Saturday and Monday totals. There is no clearing activity on Sunday.
Settlement can be performed only after clearing has occurred.
<<glossary:FAST>> facilitates settlement of transactions through:
- Delivery of ISO 8583 (93) Settlement file raw messages (
<<glossary:JSON>>/<<glossary:XML>>wrapped) to the client - Delivery of parsed Settlement data: presentments, fees, Interchange, chargebacks
- Ability to re-deliver old data to the client. The client uses web service to request data
Network settlement reports
Everyday, Paymentology forwards raw network settlement reports to you. These reports are received by Paymentology directly from the card network.
File formats:
- Visa: VSS reports, EP reports
- Mastercard: T112, T140, TQR4 reconciliation reports
For report delivery, Paymentology necessitates the following details:
<<glossary:SFTP>>host name or IP address along with the port number.- Structure of the
<<glossary:SFTP>>file directory. <<glossary:SFTP>>username and password.- BIN (Visa) or ICA (Mastercard) information.
Reconciliation
This final, pivotal step, conducted by the finance department, ensures the balance of general ledgers, payment of taxes and duties, and realization of project benefits.
It serves as a critical stage for error identification, such as incorrect charges, fraud, and misallocated accounts.
Visa settlement reconciliation
Visa provides multiple reports that you can reconcile against, accommodating various reconciliation periods.
- VSS-110: Settlement Summary Report (Daily VSS Settlement Report)
- VSS-110-M: Monthly Settlement Summary Report (Monthly VSS Settlement Report)
- VSS-111: Consolidated Settlement Summary Report (VSS Periodic Report)
Visa's clearing and settlement schedule
Visa settles transactions with clients through different settlement services, each with specific settlement windows. These windows denote times when settlements occur. Additionally, Visa offers intra-day settlement services for particular circumstances. International Settlement, for instance, starts daily at around 03:00 a.m. Pacific Time (PT), which corresponds to 10:00 GMT from April through October and 11:00 GMT from October through April.
If client files are not fully transmitted by the initiation of the International Settlement window, they are partially processed for inclusion in settlement on that day, with the remaining portion processed for inclusion the following calendar day.
Clients utilizing other settlement services can specify the closure time for these services before international settlement.
Mastercard settlement reconciliation
Mastercard provides several reports that you can reconcile against, accommodating various reconciliation periods.
- T112: IPM Reconciliation File
- T140: GCMS reconciliation reports
- TQR4: Mastercom reconciliation reports
Mastercard's clearing and settlement schedule
Mastercard processes clearing data six times per day and issuing processors can elect to receive this data up to six times per day. Four to five times per day is deemed to be sufficient as most clearing data is processed in the first two cycles of the day.
NOTE: In addition to the six primary clearing cycles, a seventh clearing cycle exists exclusively for Mexico domestic switching transactions.
Mada settlement reconciliation
Mada provides the following reports that you can reconcile against, accommodating various reconciliation periods.
- mada Transaction Log File
- mada Settlement File
Mada's clearing and settlement schedule
The financial transaction processed through Mada is logged according to the below cutover:
- ATM cutover time occurs at 6:30 am
- POS and eCom cutover time occurs at 4:00 am.
Basic reconciliation guidelines
Here's a brief overview of how to carry out your daily reconciliation process:
Overview of various files involved
- Settlement reports - Sent by Mada to you (the client).
- TLF files - Sent by Mada to Paymentology.
- Daily reports - Sent by Paymentology to you (the client). These daily reports include Authorizations, Presentments.
Note: Paymentology processes the TLF file and generates the Presentments report, which you should use for reconciliation purposes.
Reconciliation steps
- Match all approved transactions on your system with the Authorizations report.
- Cross-check transactions from the Authorizations report against the Presentments report.
- Verify the amounts in the Presentments report against the Settlement report (sent to you by Mada).
Any discrepancies found should be reviewed manually by your internal reconciliation team.
Summary of requirements and responsibilities
Below is an outline of the responsibilities held by both you and Paymentology when launching a card program on our platform.
| Responsibility | Paymentology | You (Client) |
|---|---|---|
| Receive and process raw network clearing data files | Responsible | |
| Delivering clearing data through webhooks | Responsible | |
| Receive clearing webhooks and handle the processing of credits and debits | Responsible | |
| Delivering raw network settlement files to the customer | Responsible | |
| Delivering daily reports i.e., presentment, interchange, fees to the customer | Responsible | |
| Reconciliation of the data | Responsible | |
| Transferring funds for settlement | Responsible |
Refer to your card scheme's reference material for details on their daily cycles.
Updated 7 months ago
