Skip to main content
The End of Day file is a daily record of financial transactions where DCC was offered to the cardholder. Fexco uses it to reconcile and settle DCC activity between the acquirer or processor and the DCC provider. This page explains which transactions you must include in the file and which you must exclude.

Inclusion rules overview

A batch process generates the EOD file. It runs in parallel to, and independently of, any clearing files that the acquirer or processor submits to the card schemes. The EOD file is not a copy of the scheme clearing file and is not routed through the schemes. Its contents must still be consistent with the transactions cleared to the schemes, so that Fexco can reconcile both. A transaction must be included in the EOD file when all of the following apply:
  • It is a financial transaction, meaning it results in a posting to the cardholder’s account.
  • The issuer approved it, or it was approved on the issuer’s behalf (for example, stand-in processing).
  • DCC was offered to the cardholder, and the cardholder either accepted or declined the offer.
The two DCC outcomes are defined as follows: Each record must include the DCC outcome (accepted or declined) so that Fexco can identify both scenarios.

How opt-in and opt-out transactions differ in the file

When a cardholder accepts DCC, the file record shows the converted currency, amount, and exchange rate. When a cardholder declines DCC, the transaction is processed in the merchant’s base currency, so the file record reflects that. The following table compares the field values for each outcome in the XML I-file. For the legacy I-file and V-file formats, the same principle applies: an opt-out record uses the base currency as the transaction currency, the base amount as the transaction amount, and an exchange rate of 00000001.0000.

Processing cycle requirements

The EOD file must align with the 24-hour processing cycle that the acquirer or processor uses, including its cut-off time. This ensures that Fexco can match the file to the transactions in each cycle. You must include each transaction once only, in the cycle in which it was completed (Single Message) or presented for clearing (Dual Message).

Single Message rules

In a Single Message environment, authorization, clearing, and settlement are completed in one online message. You include transactions based on the outcome of the financial message itself. The following table lists the message type indicators (MTIs) and the rule for each one. A request and response pair must produce one record only.

Dual Message rules

In a Dual Message environment, authorization and clearing are separate processes. The DCC decision is captured at authorization, but you include a transaction in the EOD file only when it is presented for clearing. The following table lists the message types and the rule for each one. You must not include authorizations and preauthorizations that are never presented for clearing.

Refund and partial approval rules

Refunds and partial approvals follow the same rules in Single Message and Dual Message environments. Refunds (credits) must be included where they are linked to an original DCC transaction. You must exclude standalone refunds that have no linked original DCC transaction. Partially approved transactions must be included for the approved amount only. Fexco quotes the DCC rate and converted amount to the cardholder on the full transaction amount. A partial approval can therefore create a mismatch between what the cardholder accepted and what is processed. We recommend one of the following approaches:
  • The host or terminal handles partial approvals appropriately for DCC transactions.
  • Where this is not possible, you do not send the partial approval indicator on the authorization request for DCC transactions.

Transactions always excluded

You must exclude the following transactions regardless of message type:
  • Transactions where DCC was not offered. For example, the card is ineligible, the card was issued in the merchant’s local currency, the merchant or merchant ID (MID) is not enabled for DCC, or the rate request failed or timed out.
  • Declined, failed, cancelled, or voided transactions, together with the corresponding sale.
  • Preauthorizations, including incremental preauthorizations. You include only the completion (Single Message) or the first presentment (Dual Message).
  • Duplicate or repeat submissions of a transaction that is already included.

Next steps

After you confirm which transactions to include, build and submit your file: