In payment systems every transaction completes within a few seconds, yet dozens of checks, verifications, and security layers run in the background. The purpose of these layers is to protect not only transaction speed but also financial integrity.
In this post, we cover the precautions that need to be taken in the authorization and clearing processes, the critical role of the reversal mechanism, and the financial loss scenarios most commonly encountered in the field.
Risk Controls at the Authorization Stage
Authorization is the first stage, where the validity, balance, and transaction permissions of the card are checked. A mistake made at this point can turn into financial losses during the clearing process.
Core Precautions
- Limit checks: Systematically verifying the card's daily, per-transaction, and sector-based limits.
- PIN and CVV verification: The most basic security layer that prevents counterfeiting, especially in online transactions (CNP).
- Velocity checks: Triggering an alert when many transactions are made with the same card in a short time.
- Cross-border risk assessment: The risk score should be raised when the countries of the card and the POS differ.
- ISO 8583 field checks: Format and consistency checks should be performed on fields such as DE 2, DE 4, DE 11, DE 37, DE 41, and DE 42.
Message Consistency
- Every authorization message is identified by a unique STAN (DE11) and RRN (DE37). This combination must not be reused in repeated (replay) messages.
- In dual message (authorization + financial) transactions, the system monitoring layer must verify that these two messages match.
Consistency in the Clearing Process
The clearing process is the stage in which authorized transactions are posted financially to accounts. Any inconsistency here directly creates a risk of loss.
Data and Accounting Controls
- Authorization–clearing matching: The DE37 (RRN), DE38 (Auth Code), and DE62 (Issuer Data) fields must match exactly.
- Amount mismatch checks: Especially in foreign currency transactions, ISO 4217 currency codes (DE49) must always be verified.
- Duplicate clearing prevention: If the same transaction is sent twice, the system must reject it.
Reconciliation and Reporting
- Differences between authorization, clearing, and accounting records should be detected with daily automated reconciliation systems.
- Erroneous, missing, or duplicate transactions should be analyzed daily as an “exception report”.
Reversal Mechanism: The Element That Protects Financial Balance
A reversal is the process of releasing the previously reserved balance when a transaction ends unsuccessfully after authorization or cannot be completed because of technical errors.
If the reversal process is not managed correctly, problems such as unjustified blocks or double charges can occur on both the cardholder and the bank side.
When Is a Reversal Sent?
- When a transaction cannot be completed in time due to a POS or network outage, a “timeout reversal” is sent by the terminal or the issuer host.
- When a transaction is cancelled by the merchant (for example, when the cancel key is pressed on the POS), a manual reversal is created.
- If a transaction ends without approval between the acquirer and the issuer after a network timeout, the acquirer side triggers an automatic reversal.
Technical Implementation: ISO 8583 Fields
A reversal message (MTI 0400 or 0420) must reference the original transaction. To do this:
- The DE90 (Original Data Elements) field carries the DE7, DE11, DE32, and DE37 information of the transaction being reversed.
- An error code other than “00” returned in DE39 (Response Code) as the transaction result can be the trigger for a reversal.
- The DE95 (Replacement Amounts) field is used in some networks for partial amount refunds.
Operational Precautions
- Time rule: If timeout reversals are not sent within a defined period (e.g., 30 seconds), the transaction remains as an “open authorization”.
- Tracking system: The transaction monitor layer must verify that every reversal message matches its related authorization message one to one.
- End-of-day monitoring: At the end of the day, open (unreversed) authorizations should be identified and closed manually.
Typical Consequences of Reversal Errors
- The cardholder's balance goes down, but the transaction did not take place.
- If the acquirer side sends a transaction without a reversal into clearing again in the clearing file, a double charge can occur.
- Because the issuer does not receive the reversal record, the item may remain as an unmatched transaction.
Most Common Financial Loss Scenarios
The financial loss scenarios frequently encountered in real field experience generally fall into three main categories: transactional errors, systemic inconsistencies, and operational gaps.
Failure to Send a Timeout Reversal
- The POS or acquirer host does not send the reversal message in time when the transaction fails.
- The cardholder's account is blocked, while on the clearing side the transaction enters clearing again → risk of double charge.
Duplicate Authorization
- The terminal reuses the same STAN or RRN.
- The issuer approves both authorizations, but only one enters clearing → block difference and customer complaint.
Reversal–Clearing Mismatch
- The issuer receives the reversal, but the acquirer still sends the clearing file.
- In this case a “duplicate settlement” occurs on the issuer side → the loss is booked to the issuer.
Amount Mismatch
- Especially in foreign currency transactions, the authorization amount and the clearing amount are calculated differently.
- Exchange rate difference, decimal error, or rounding difference → accounting difference.
Late Reversal (Stale Reversal)
- A message sent at the end of the day in place of a reversal arrives after clearing.
- The issuer does not accept the reversal, and the acquirer cannot cancel the clearing record → a long-running dispute.
Terminal or Network Replay
- The POS or the network resends a previously approved message.
- If no replay check (STAN + RRN) is performed, the transaction is processed a second time → duplicated debit.
What Should Be Considered for the System to Run Smoothly?
- Reversal simulation: Network outage and timeout scenarios should be tested in the development environment.
- Automated reconciliation: Daily matching should be performed between reversal, clearing, and core banking records.
- Fraud engine integration: Merchants or terminals that send a large number of reversals should be monitored closely.
- PCI DSS logging requirements: Every reversal transaction should be logged in line with requirements 10.2 and 10.5.
Conclusion
Preventing financial losses in payment systems is possible not only through fraud measures but also by maintaining technical integrity.
Authorization, clearing, and reversal processes are the three links of the chain – when one is weak, the whole system is put at risk.
For this reason, applying the reversal mechanism on time and correctly is the foundation of financial security and customer satisfaction.
