> ## Documentation Index > Fetch the complete documentation index at: https://docs.fexco.com/llms.txt > Use this file to discover all available pages before exploring further. # How transaction import works > Learn what DCC transaction import is, why files are submitted to Fexco, and how the daily file cycle works. Transaction import is the process of reporting that outcome to Fexco by submitting a daily file that contains all DCC and domestic transactions. This page explains why transaction import exists, what the file contains, how the daily submission cycle works, and how Fexco confirms the result. ## Purpose of transaction import The rate service provides exchange rates in real time, but its role ends when the cardholder accepts or declines the DCC offer. It doesn't process or settle transactions, so Fexco doesn't know how each transaction was completed. The transaction file fills that gap by feeding two systems: * **Mercury**: Fexco's transaction processing system, which validates the file and records each transaction. * **Fresh Insights**: Fexco's business intelligence and reporting platform, which generates revenue reports, throughput analysis, and commission calculations. Without a transaction import, Fexco cannot calculate commissions, generate settlement reports, or reconcile DCC revenue for your merchants. ## What a transaction file contains A transaction file reports card transactions processed through your terminals, ATMs, or e-commerce channels during a given period. The file includes three categories of transaction: * **Converted transactions**: the cardholder accepted the DCC offer and paid in their home currency. * **Unconverted transactions**: the cardholder was offered DCC but declined it. These must be included under the same Merchant Originator Tag as converted transactions. * **Domestic transactions**: the card was not eligible for DCC (for example, a domestic card), so no offer was made. Fexco uses all three categories to calculate DCC hit rates and revenue. Each transaction record includes: | Data | Description | | :- | :- | | Merchant and terminal identifiers | The merchant ID and terminal or ATM ID where the transaction occurred. These must match the identifiers used during [merchant boarding](https://docs.fexco.com/dcc/guides/merchant-boarding/how-it-works.md). | | Card BIN | The first six to twelve digits of the card used in the transaction. | | Transaction type | Whether the transaction is a sale (`debit`) or refund (`credit`). | | Base amount | The amount in the merchant's base currency. | | Transaction currency and amount | The currency the cardholder chose and the converted amount. For domestic transactions (where the cardholder did not convert), this matches the base currency and amount. | | Exchange rate | The rate applied to the conversion. For domestic transactions, this is `1.00`. | | Date and time | When the transaction occurred, in [ISO 8601](https://www.iso.org/iso-8601-date-and-time-format.html) format with UTC offset. | | Entry mode | How the card was presented: `magswipe`, `chip`, `contactless`, `eCommerce`, `keyed`, `signed`, or `mailTelephoneOrder`. | > [!NOTE] > > In the XML I-file schema, the entry mode field is named > `customerInstructions`. The receipt below shows how these fields appear on a real DCC receipt. ![POS Visa sale receipt showing the sale amount, exchange rate, margin percentage, and total in the cardholder's currency.](https://mintcdn.com/productdocumentation-fexco-com/-PF5EWDCkp1K-lBR/images/pos-visa-sale-receipt.png?fit=max\&auto=format\&n=-PF5EWDCkp1K-lBR\&q=85\&s=80344b3f10a24444c6201eb8adc5fd56) POS sale receipt (Visa) showing the exchange rate, margin, and converted amount. > [!TIP] > > See [Screens and receipts](https://docs.fexco.com/dcc/developer-resources/screens-and-receipts.md) for the full set of receipt examples across POS, ecommerce, and ATM channels. ## Which transactions to include The transaction file is a daily record of all transactions where DCC was offered. It runs in parallel to any clearing files you submit to the card schemes. Its contents must be consistent with the transactions cleared to the schemes so that both can be reconciled. ### General rule Include a transaction when all of the following apply: * It is a financial transaction that results in a posting to the cardholder's account. * It was approved by the issuer (or on the issuer's behalf, for example, stand-in processing). * DCC was offered to the cardholder, whether the cardholder accepted or declined. Each record must indicate the DCC outcome. ### Processing cycle The file must align with the 24-hour processing cycle, including cut-off time, used by your organisation. Each transaction must be included once only, in the cycle in which it was completed (single message) or presented for clearing (dual message). > [tab] Single message (SMS) > > In a single message environment, authorisation, clearing, and settlement are completed in one online message. Include transactions based on the outcome of the financial message. > > | Message type | Rule | > | :- | :- | > | 0200 / 0210 (Financial request / response) | Include where the response indicates approval or partial approval. Exclude declines. | > | 0220 / 0230 (Financial advice / response) | Include approved advices, for example stand-in approvals, pre-authorisation completions, and force-post transactions. | > | 0400 / 0420 (Reversal request / advice) | Include full and partial reversals where the original transaction is in the file. Reversals must carry the same DCC currency and rate as the original. | > | Repeat messages (0201, 0221, 0401, 0421) | Exclude where the original message has already been included, to avoid duplicates. | > | 01xx, 03xx, 06xx, 08xx | Exclude (authorisation, file update, administrative, and network management). | > > A request and response pair must produce one record only. > [tab] Dual message (DMS) > > In a dual message environment, authorisation and clearing are separate processes. The DCC decision is captured at authorisation, but include the transaction only when it is presented for clearing. > > | Message | Rule | > | :- | :- | > | First presentment (purchases and refunds) | Include where DCC was offered at authorisation. Refunds must be linked to an original DCC transaction. | > | Second presentment / re-presentment | Exclude (dispute cycle). | > | Authorisation request / response (0100 / 0110) | Exclude (no posting to the cardholder's account). | > | Authorisation reversal (0400 / 0420) | Exclude. | > | Chargebacks and other dispute messages | Exclude. | > | File header/trailer, addenda, reconciliation, and administrative records | Exclude. | > | Fee collection records | Exclude. | > > Authorisations and pre-authorisations that are never presented for clearing must not be included. ### Refunds Include refunds where they are linked to an original DCC transaction, in both single and dual message environments. Exclude standalone refunds with no linked original DCC transaction. ### Partial approvals Include partially approved transactions for the approved amount only. Because the DCC rate and converted amount are quoted on the full transaction amount, partial approvals can create a mismatch between what the cardholder accepted and what is processed. Either handle partial approvals appropriately for DCC transactions at the host or terminal, or do not send the partial approval indicator on the authorisation request for DCC transactions. ### Transactions always excluded Exclude the following regardless of message type: * Transactions where DCC was not offered (ineligible cards, domestic cards, merchants not enabled for DCC, or a rate request that failed or timed out). * Declined, failed, cancelled, or voided transactions with the corresponding sale. * Pre-authorisations, including incremental pre-authorisations. Only the completion (single message) or first presentment (dual message) is included. * Duplicate or repeat submissions of a transaction already included. ## Transaction import file formats Fexco supports three transaction file formats. All three serve the same purpose, but they differ in structure and which integrations use them. | Format | Structure | Typical use | | :- | :- | :- | | XML I-file | XML with XSD validation. | ATM operators, acquirers, and PSPs who process transactions through their own systems. | | I-file | Fixed-length record format with financial and logical integrity checks. | Merchants and PSPs who submit an information-only file alongside their existing payment processing. | | V-file | Positional record format with financial and logical integrity checks. Record length varies by transaction type. Supports additional segments for chip data, contactless, airline itineraries, and 3D Secure. | Merchants and PSPs who submit a full transaction file covering all sales and refunds. | See [Choose a file format](https://docs.fexco.com/dcc/guides/transaction-import/file-format.md) for a detailed comparison of when to use each format. ## How the daily file cycle works Transaction import follows a daily cycle of building, submitting, and reviewing files via [Secure File Transfer Protocol (SFTP)](https://docs.fexco.com/dcc/guides/getting-started/security-setup.md#secure-file-transfer-sftp): 1. **Build the transaction file** At the end of each business day (or at the agreed reporting interval), collect all card transactions from your terminals, ATMs, or e-commerce channels and format them into the file format you have agreed with Fexco. Each file must pass integrity checks before submission. See [Understanding file integrity](#understanding-file-integrity) below. 2. **Encrypt and submit via SFTP** Upload the file to the `Incoming` folder on your designated Fexco SFTP server. XML I-files must be encrypted with [GNU Privacy Guard (GPG)](https://docs.fexco.com/dcc/guides/getting-started/security-setup.md#file-encryption-gpg) before submission (the encrypted file uses a `.gpg` suffix). I-files and V-files follow the encryption requirements agreed during [security setup](https://docs.fexco.com/dcc/guides/getting-started/security-setup.md). > [!WARNING] > > When submitting multiple files on the same day, wait for the > confirmation file from the previous submission before sending > the next file. 3. **Fexco validates the file**: Fexco picks up the file automatically at a scheduled time and validates its structure, integrity, and content. If the file passes validation, the transactions are loaded into Mercury and Fresh Insights. 4. **Review the confirmation files** Fexco places confirmation files in the `Outgoing` folder on your SFTP server. The confirmation tells you whether the file was accepted, partially accepted, or rejected. Each build-and-submit guide explains the confirmation file format for its file type. > [!TIP] > > The confirmation shows the file was fully accepted with no > rejected transactions. 5. **Correct and resubmit if needed**: How you resubmit depends on whether the entire file was rejected or only some transactions failed. * **Whole file rejection**: the file failed structural or integrity validation and no transactions were processed. Correct the errors and resubmit the full file without incrementing the sequence number. * **Partial rejection**: the file was accepted but some individual transactions were rejected. Resubmit only the rejected transactions in a new file with the sequence number incremented. For XML I-files, a status of S5 indicates a full file rejection. The following diagram shows the same cycle between your system and Fexco. Click each step to walk through the daily cycle ## Understanding file integrity I-files and V-files have two levels of integrity checking. A failure in either level causes the entire file to be rejected. XML I-files use [XSD schema validation](https://docs.fexco.com/dcc/guides/transaction-import/build-and-submit/xml-i-file.md#validate-against-the-xsd) instead of the record-level checks described below. ### Financial integrity Transaction records roll up into a hierarchical structure that must balance at every level: 1. **Transaction records** are grouped by merchant, terminal, and currency. 2. **Summary records** total the number and net value of transactions for each group. 3. **Claim records** total the number and net value of all summary records for each merchant. 4. **Trailer records** total the number and net value of all claim records in the file. If any total does not reconcile with the records beneath it, the file fails financial integrity and is rejected. ### Logical integrity Every record in the file is assigned a sequence number starting at `0000001` and incrementing by one. The trailer record contains the total record count, which must equal the highest sequence number used. Any break in numbering or an incorrect total causes a logical integrity failure and the file is rejected. ## Next steps Now that you understand what transaction import is and how the daily file cycle works, choose your file format and start building your file: * [Choose a file format](https://docs.fexco.com/dcc/guides/transaction-import/file-format.md): compare XML I-file, I-file, and V-file to decide which format to use. * [Build and submit an XML I-file](https://docs.fexco.com/dcc/guides/transaction-import/build-and-submit/xml-i-file.md): step-by-step guide for the XML I-file format. * [Build and submit an I-file](https://docs.fexco.com/dcc/guides/transaction-import/build-and-submit/i-file.md): step-by-step guide for the fixed-length I-file format. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.