Operations Advisory

Clearing, Settlement & Reconciliation Advisory

The journey from an approved authorisation to final settled funds involves multiple clearing file formats, multilateral net positions and reconciliation disciplines that few practitioners understand end-to-end. FinPay Consultants provides specialist advisory across the full post-authorisation stack — from BASE II and VCE clearing through to interchange optimisation and exception management.

The Authorisation-to-Settlement Flow

Card transactions traverse three distinct phases before funds move between financial institutions — authorisation, clearing and settlement. Understanding the handoffs between these phases, and the data integrity requirements at each stage, is foundational to building robust operations.

01

Authorisation

The real-time approval decision — issuer host evaluates the transaction and returns an approval or decline response via the scheme network (VisaNet, Banknet). The authorisation record is held in the issuer's shadow ledger and the acquirer's transaction log, but no funds move at this stage. A unique System Trace Audit Number (STAN) and Retrieval Reference Number (RRN) are assigned — these become the linking keys between authorisation and clearing records.

02

Clearing

The merchant's acquirer submits the cleared transaction data to the scheme in a structured clearing file — BASE II / VCE for Visa, IPM for Mastercard. The clearing record carries full transaction detail: PAN, amount, merchant category code, POS entry mode, and where applicable, EMV data elements (DE 55). The scheme validates each record against edit package rules, computes interchange fees and net positions, and routes financial obligations to the relevant issuer. Clearing typically occurs within 1–2 business days of the original authorisation.

03

Settlement

The scheme calculates multilateral net settlement positions — each participant's aggregate obligation or entitlement across all transactions in the clearing cycle. Net positions are settled through central bank or correspondent banking channels (e.g., Fedwire, CHAPS, TARGET2) via the scheme's settlement bank. Issuers receive net settlement reports (VSS for Visa, MCBS for Mastercard) that must reconcile against internally computed positions. Settlement failures or position breaks require same-day resolution to avoid funding shortfalls.

Clearing vs. Settlement: A common point of confusion — clearing is the exchange of transaction data and computation of net financial positions; settlement is the actual movement of funds between financial institutions. A card programme can have efficient clearing but dysfunctional settlement reconciliation, and vice versa. Both disciplines require dedicated operational expertise.

Visa Clearing: BASE II & VCE

BASE II Architecture

BASE II is Visa's legacy batch clearing system — the backbone of Visa transaction processing for decades. In the BASE II model, acquirers submit clearing files (TC05 records for sales, TC15 for credits, TC25 for chargebacks) to VisaNet on a defined cut-off schedule. VisaNet aggregates incoming records, applies the Edit Package validation rules, computes interchange for each transaction and produces outbound settlement files to issuers. Participants interact with BASE II via the Visa SMS (Single Message System) or DMS (Dual Message System) depending on whether authorisation and clearing are combined in a single message or separated.

VCE — Visa Clearing Exchange

VCE (Visa Clearing Exchange) is Visa's next-generation clearing infrastructure, replacing the batch-oriented BASE II model with a message-based, near-real-time clearing architecture. Key architectural differences:

  • Message-based vs. batch-file: VCE processes individual clearing messages rather than batched fixed-width files, enabling faster exception detection and more granular transaction-level status tracking.
  • ISO 20022 alignment: VCE introduces ISO 20022-compatible data structures alongside Visa's proprietary format — a significant change management undertaking for processors and host developers accustomed to BASE II field layouts.
  • Enriched data: VCE supports enhanced data elements not present in BASE II — including Level 2/3 purchase data, extended merchant information and richer tokenisation metadata — enabling improved interchange qualification and analytics.

Edit Package Compliance

Every clearing record submitted to VisaNet is validated against the Edit Package — a comprehensive set of rules governing mandatory data elements, field format compliance, amount limits and logical consistency between related fields. Edit categories determine the outcome of a failing record:

  • Reject edits: The clearing record is rejected outright. The acquirer must correct and resubmit within scheme-defined windows, or the transaction may become unrecoverable. Common reject triggers include missing mandatory DEs, invalid merchant category codes and amount field format errors.
  • Accept-with-error (AWE): The record is accepted for clearing but flagged — often resulting in interchange downgrade rather than outright rejection. AWE conditions are a primary driver of interchange leakage for acquirers.
  • Warning edits: Informational flags that do not affect clearing outcome but indicate data quality issues requiring remediation — important for maintaining scheme compliance scores.

T&E Clearing Requirements

Travel and Entertainment (T&E) transactions — airlines, hotels, car rental — carry specific clearing requirements under Visa's T&E programme rules. Estimated authorisations (common for hotel check-in and car rental) must be matched to final clearing amounts within defined variance tolerances. Incremental authorisations for hotel extended stays must follow specific DE sequencing. Failure to clear T&E transactions correctly is a frequent source of interchange downgrade and scheme compliance issues for acquirers serving hospitality merchants.

Visa Settlement Service (VSS)

VSS is the reporting and settlement delivery platform for Visa participants. VSS delivers net settlement reports (NSRs) detailing each participant's daily settlement position, interchange obligations and fee assessments. Issuers must reconcile their internally-computed net position against the VSS NSR — breaks require investigation and escalation to Visa Settlement Operations within same-day timelines. VSS also delivers position detail reports (PDRs) providing transaction-level clearing detail for reconciliation against internal transaction logs.

Mastercard Clearing: IPM & GCMS

IPM File Format & GCMS

Mastercard's clearing operates through the Global Clearing Management System (GCMS), which processes Interchange Posting and Management (IPM) files. IPM is a binary record format — each clearing record is a Presentation Exchange (PEX) message containing a hierarchical set of Data Elements (DEs) similar in concept to ISO 8583 but with distinct field mappings and record types.

Key IPM record types include:

  • Financial Presentment (1240): Standard sale clearing record
  • Financial Presentment Reversal (1442): Reversal of a previously submitted clearing record
  • Chargeback (1442): Issuer-initiated dispute record
  • Second Presentment (1240): Acquirer response to chargeback
  • Arbitration Chargeback (1442): Escalated dispute record

IPM files are submitted by acquirers and processors to GCMS on defined clearing cycles. GCMS validates records against Mastercard's edit rules, calculates interchange fees using the applicable interchange programme, and computes multilateral net settlement positions for delivery via MCBS.

MasterCom: Dispute Operations

MasterCom is Mastercard's web-based dispute management system — the operational interface for issuers and acquirers to file, respond to and track chargebacks and retrieval requests. Key MasterCom functions:

  • Case filing: Issuers initiate chargebacks by selecting the applicable reason code, uploading supporting documentation and submitting via MasterCom's structured workflow. Case reference numbers link to the underlying IPM chargeback record.
  • Documentation upload: MasterCom enforces document type and size requirements — accepted formats include PDF, JPG and TIF. Evidence submitted outside MasterCom's portal (e.g., by fax or email) is not accepted under current dispute rules.
  • Case tracking: Real-time case status visibility, response deadline tracking and automated notifications for incoming second presentments or arbitration filings.

DE 55 (ICC Data) Clearing Matching

DE 55 carries the EMV chip data from the original transaction — cryptogram, ATC (Application Transaction Counter), IAD (Issuer Application Data) and other ICC primitives. A critical and frequently misunderstood requirement: the DE 55 data submitted in clearing must logically match the DE 55 in the original authorisation. Discrepancies — particularly in the cryptogram or ATC value — indicate a potential data integrity issue and can trigger issuer dispute rights. Processors performing clearing-side DE 55 enrichment (adding clearing-specific data elements) must take care not to corrupt authorisation-derived chip data.

MCBS (Mastercard Clearing and Settlement): Mastercard's settlement infrastructure delivers net settlement files to participants' settlement banks. MCBS settlement reports include the Daily Settlement File (DSF) — equivalent to Visa's NSR — and the Interchange Reimbursement Fee (IRF) report detailing interchange obligations by transaction category. Reconciliation of MCBS DSF against internally-computed positions must be completed within the settlement bank's cut-off window to avoid same-day funding shortfalls.

Reconciliation Operations

Reconciliation is the discipline of matching authorisation records to clearing records to settlement positions — identifying and resolving every break before it creates a financial loss or compliance issue. FinPay Consultants designs reconciliation frameworks that operate at scale across multi-scheme, multi-currency portfolios.

Authorisation-to-Clearing Match Process

The primary reconciliation control is the match between each authorisation record and its corresponding clearing record. Match keys and tolerance rules:

  • STAN (System Trace Audit Number): The 6-digit trace number assigned by the acquirer at authorisation. STAN is the primary matching key between auth and clearing records on the acquirer side. STANs recycle daily (000001–999999) so must be combined with date and terminal ID for uniqueness in multi-terminal environments.
  • RRN (Retrieval Reference Number): The 12-digit reference assigned in the authorisation response — used as the primary matching key for issuers and for dispute reference. RRN uniqueness must be enforced at the processor level; duplicate RRNs are a frequent source of unmatched clearing breaks.
  • Amount tolerance: Clearing amounts may legitimately differ from authorisation amounts within scheme-defined tolerances — hotel estimated auth vs. final folio, restaurant pre-auth vs. including tip. Tolerance rules vary by MCC: restaurant tips may be up to 20% above auth amount; fuel pump pre-auths may differ substantially from final fuelling amount. Hard amount mismatches outside tolerance windows require investigation and may trigger dispute rights.

Shadow Ledger Reconciliation

The shadow ledger is the issuer's internal record of authorised-but-not-yet-cleared transactions — the "float" between approval and clearing. Shadow ledger management requires accurate handling of:

  • Force-posts: Clearing records that arrive without a corresponding authorisation — common for offline transactions, stand-in approvals and batch merchants. Force-posts must be validated against BIN rules and amount limits before posting to the cardholder account.
  • Reversals: Authorisation reversals cancel the shadow ledger hold without a corresponding clearing record. Incomplete reversal processing — where the shadow hold remains after a reversal message — reduces cardholder available credit and generates service complaints.
  • Partial approvals: The issuer approved a partial amount (common for prepaid cards). The clearing record must match the approved — not requested — amount. Partial approval clearing failures are a leading source of acquirer disputes.

Interchange Optimisation

Interchange fees — paid by the acquirer to the issuer on each cleared transaction — are determined by the applicable interchange programme, which is assigned at clearing based on transaction attributes. Interchange downgrade occurs when a transaction qualifies for a lower (less favourable, for the issuer) interchange tier due to missing or incorrect data elements in the clearing record. Key optimisation levers:

  • Downgrade analysis: Systematic review of clearing records that received lower interchange qualification than the optimal programme. Common downgrade triggers: missing DE 61 (POS data), incorrect POS entry mode, absent Level 2/3 data for corporate card transactions, late clearing (beyond the scheme's submission window).
  • DE 61 correction: DE 61 (Point of Service Data) carries POS terminal capability flags — card presence, cardholder presence, terminal type, PIN capability. Incorrect DE 61 values are the single most common cause of interchange downgrade in acquirer portfolios, and often arise from misconfigured terminal profiles rather than transaction-level errors.
  • POS entry mode normalisation: Clearing records from omnichannel merchants frequently carry incorrect POS entry mode codes — a magnetic stripe fallback on a chip-capable terminal filed as EMV, or an e-commerce transaction filed with a card-present entry mode. Normalising entry modes across the clearing estate improves interchange qualification and reduces liability shift exposure.

Common Reconciliation Breaks

  • Unmatched clearing: A clearing record arrives with no corresponding authorisation in the shadow ledger — either because the authorisation expired, was reversed, or was processed under a different STAN/RRN. Unmatched clearing posts must be investigated before posting to avoid double-charging cardholders.
  • Duplicate transactions: Two clearing records with identical matching keys — frequently caused by batch retry logic or merchant terminal configuration errors. Duplicate detection at clearing input is essential; failure to detect duplicates before account posting generates chargeback liability under Visa 12.6 and MC 4834.
  • Currency conversion differences: Multi-currency programmes applying DCC (Dynamic Currency Conversion) or cross-border transaction processing may show minor settlement amount differences due to exchange rate timing. Tolerance bands and systematic rounding reconciliation are required for portfolios with significant cross-border volume.

VCE Edit Package Categories

The following table summarises the principal edit categories applied by Visa Clearing Exchange during clearing record validation, the data elements most commonly checked, the error classification and the practical impact on acquirer operations.

Edit Category DE(s) Checked Error Type Acquirer Impact
Mandatory Field Presence DE 2 (PAN), DE 4 (Amount), DE 12/13 (Date/Time), DE 42 (Card Acceptor ID) Reject Record rejected; must resubmit corrected record within 5 business days or transaction is lost
Field Format / Length DE 2 (PAN length), DE 37 (RRN format), DE 41 (Terminal ID length) Reject Record rejected; indicates upstream data capture or truncation issue at POS or processor
Amount Reasonableness DE 4, DE 6 (Cardholder Billing Amount), DE 9 (Conversion Rate) Accept-With-Error Record accepted but flagged; may trigger interchange downgrade or manual review
POS Data Consistency DE 22 (POS Entry Mode), DE 61 (POS Data) Accept-With-Error Interchange downgrade to base rate; primary driver of acquirer interchange leakage
EMV / Chip Data Integrity DE 55 (ICC Data), DE 23 (Card Sequence Number) Accept-With-Error / Reject Liability shift reversion; issuer may initiate chargeback citing missing or corrupted chip data
Merchant Category Validity DE 26 (Card Acceptor Business Code / MCC) Accept-With-Error Incorrect MCC causes interchange misclassification and may trigger scheme compliance review
Settlement Currency DE 49 (Transaction Currency Code), DE 50 (Settlement Currency Code) Reject Record rejected; incorrect currency codes prevent accurate settlement position computation
Duplicate Detection DE 37 (RRN), DE 41 (Terminal ID), DE 12/13 (Date/Time), DE 4 (Amount) Reject Duplicate record suppressed; original already processed; acquirer must investigate source of duplicate submission

Frequently Asked Questions

In gross settlement, each payment obligation is settled individually and in full. In net settlement — the model used by Visa and Mastercard — all payment obligations between participants are offset, and only the net position is settled at the end of the settlement cycle. Under the Visa Net Settlement Service and Mastercard Settlement, each participant's clearing records are aggregated across the day and the net debit or credit is applied to their settlement account at the designated settlement bank. For smaller issuers and acquirers the net settlement model significantly reduces intraday liquidity requirements. The risk is settlement finality: until settlement completes, participants carry credit exposure to the central counterparty. Schemes mitigate this through settlement guarantee programmes and prefunding requirements for members below minimum financial thresholds.

Clearing reconciliation compares the acquirer's submitted clearing file against the issuer's posted authorisation records. Mismatches fall into several categories: unmatched clearing (a clearing record with no corresponding authorisation — typically a forced-post), unmatched authorisation (an approved auth with no clearing — the transaction was reversed or the merchant did not complete capture), and amount mismatches (clearing amount differs from authorisation amount beyond scheme tolerance, common in tip-enabled environments or multi-capture scenarios). Scheme clearing files use the Financial Transaction (1220/1240) message family in ISO 8583 or pacs.008 in ISO 20022 environments. Unresolved mismatches are escalated via scheme dispute processes; issuers must respond within defined windows (typically 5–10 business days depending on reason code) or waive the right to dispute.

Same-day or T+0 settlement models require tighter intraday liquidity management and more frequent reconciliation cycles than traditional T+1 or T+2. Key controls include: intraday liquidity limits at settlement banks with real-time monitoring; prefunding or credit line agreements sized to peak daily clearing volume; automated exception queues with defined SLAs for unmatched records; and dual-control authorisation for any manual settlement adjustments. For participants on Visa's Real-Time Settlement (RTS) or Mastercard's Enhanced Settlement Service, near-real-time fund movements require integration with RTGS systems (such as SWIFT, SEPA Instant, or domestic fast payment schemes) and the operational capacity to act on settlement notifications within minutes rather than overnight.

Optimise Your Clearing & Settlement Operations

Whether you are preparing for a VCE migration, investigating interchange leakage or designing a reconciliation framework from the ground up — our operations specialists are ready to support your programme.

Speak to an Operations Specialist