> ## 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. # XML I-file > Field reference for the XML Information file (I-file): schema, transaction elements, confirmation format, and status codes. > [!TIP] > > The XML I-file is the recommended transaction import format for all new integrations. This page is the complete field reference for the XML Information file (I-file), the transaction file format used by Automated Teller Machine (ATM) operators, acquirers, and payment service providers (PSPs) to report daily Dynamic Currency Conversion (DCC) and domestic transactions to Fexco. Use it alongside the [Build and submit an XML I-file](https://docs.fexco.com/dcc/guides/transaction-import/build-and-submit/xml-i-file.md) guide, which covers file construction, encryption, and submission. > [!NOTE] > > All element and attribute names are case-sensitive. Use camelCase > exactly as shown in this reference to prevent upload errors. ## File structure The XML I-file uses a four-level hierarchy. The following table describes each level. | Level | Element | Description | | :- | :- | :- | | 1 | `iFile` | Root element. Contains one or more `merchant` elements and the schema version attribute. | | 2 | `merchant` | Groups all transactions for one merchant ID. | | 3 | `atm`, `terminal`, or `eComm` | Groups transactions by device or channel. Each merchant can contain multiple device elements. | | 4 | `transaction` | One element per card transaction. | ## `iFile` attributes The `iFile` root element accepts the following attributes. Fexco validates the file against the XSD version identified by `schemaVersion`. | Attribute | Required | Description | | :- | :- | :- | | `schemaVersion` | Yes | Version of the XSD schema used to validate this file (for example, `25.2.0`). Provided by Fexco during onboarding. | | `fileSequenceNumber` | No | Optional attribute to supply a sequence number at the file level. The sequence number is also encoded in the filename. See [Build and submit an XML I-file](https://docs.fexco.com/dcc/guides/transaction-import/build-and-submit/xml-i-file.md#file-naming-convention) for sequence number rules. | | `disposition` | No | Specifies the processing environment. One of: `production` or `test`. Set to `test` during development. | ## `merchant` attributes Each `merchant` element groups all transactions for one merchant ID. The following table describes the supported attributes. | Attribute | Required | Type | Description | | :- | :- | :- | :- | | `merchantID` | Yes | String, 1–16 characters | Unique alphanumeric identifier for the ATM operator, point-of-sale (POS) merchant, or eCommerce merchant. Must be unique per acquirer. Also referred to as the merchant originator. | | `merchantName` | No | String, 1–128 characters | Display name or business name of the merchant. | | `acquirerID` | No | Long integer | Fexco-assigned numeric identifier for the acquirer. Provided by Fexco during onboarding. | | `merchantType` | No | Enumeration | Primary transaction source for this merchant. One of: `atm`, `pos`, or `ecomm`. | | `mccCode` | No | Integer, 4 digits, 742–9999 | Merchant Category Code (MCC) that classifies the merchant's business type. Recommended for accurate reporting. | ## Device attributes Each `merchant` element contains one or more device elements: `atm`, `terminal`, or `eComm`. All three device types support the same attributes, shown in the following table. | Attribute | Required | Type | Description | | :- | :- | :- | :- | | `atmID` / `terminalID` / `eCommID` | Yes | String, 1–11 characters | Unique alphanumeric identifier for the device or channel, defined by you. Cannot be empty. | | `batchNumber` | No | Integer, 0–999 | Batch sequence number. Rolls over after 999. If not used, set the value to `0`. Cannot be empty. | ## `transaction` attributes Each `transaction` element carries optional attributes that identify the transaction and its conversion type. The following table describes the supported attributes. | Attribute | Required | Type | Description | | :- | :- | :- | :- | | `transactionID` | No | String, max 40 characters | Free-text reference to identify the transaction. | | `rateOfferRef` | No | String, max 36 characters | Rate offer reference returned from the rate lookup call. | | `currencyConversionType` | No | String, 3 characters | Conversion method for this transaction. Case-insensitive. One of: `dcc` (Dynamic Currency Conversion) or `mcp` (multi-currency pricing). | | `disposition` | No | Enumeration | Processing environment for this transaction. One of: `production` or `test`. | ## `transaction` elements Each `transaction` element contains child elements that describe the transaction amounts, currency, and entry method. Elements must appear in the order shown in the following table. | Element | Required | Type | Description | | :- | :- | :- | :- | | `narrative` | No | String, max 250 characters | Free-text description of the transaction. Useful for fault-finding and reporting. Must appear before `bin` if included. | | `bin` | Yes | Integer, 6–12 digits | Bank Identification Number (BIN), represented by the first six to twelve digits of the card used in the transaction. | | `transactionCode` | Yes | Enumeration | Transaction type. One of: `debit` (sale) or `credit` (refund). | | `baseAmount` | Yes | Decimal | Transaction amount in the merchant's base currency. Must include a decimal point. Zero-decimal currencies (for example, JPY) do not use a decimal point. See [Currency precision](#currency-precision) for details. | | `transactionCurrency` | Yes | String, 3 characters | Currency chosen by the cardholder, using the three-letter alphabetic [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html) code (for example, `NZD`). | | `transactionAmount` | Yes | Decimal | Transaction amount in the cardholder's chosen currency. Must include a decimal point. Zero-decimal currencies do not use a decimal point. | | `exchangeRate` | Yes | Decimal | Exchange rate used between `baseAmount` and `transactionAmount`. Must include a decimal point. For transactions where the cardholder declined DCC (opt-out) or the transaction is in the base currency, use `1.00`. | | `transactionDateTime` | Yes | ISO 8601 date-time | Date and time of the transaction with time zone offset. Submit in UTC (recommended) or as an offset from UTC. The delimiter `T` between date and time is mandatory. For example: `2026-10-20T09:30:10Z`. | | `customerInstructions` | Yes | Enumeration | Card entry method. One of: `magswipe`, `chip`, `contactless`, `eCommerce`, `keyed`, `signed`, or `mailTelephoneOrder`. | | `schemeNE2ESettlementAmount` | No | Decimal | Decimal amount settled by the card scheme using non-end-to-end (NE2E) processing. Must be provided together with `schemeNE2ESettlementRate` and `SchemeNE2ESettlementCurrency`. | | `schemeNE2ESettlementRate` | No | Decimal | NE2E exchange rate used by the card scheme for `schemeNE2ESettlementAmount`. Must be provided together with `schemeNE2ESettlementAmount` and `SchemeNE2ESettlementCurrency`. | | `SchemeNE2ESettlementCurrency` | No | String, 3 characters | Currency of `schemeNE2ESettlementAmount`, using the three-letter ISO 4217 code. Must be provided together with `schemeNE2ESettlementAmount` and `schemeNE2ESettlementRate`. | | `iccData` | No | Complex element | Integrated circuit card (ICC) data wrapper. Contains one optional child element: `emvApplicationCurrencyCode`. | | `emvApplicationCurrencyCode` | No | String, 3 characters | Currency stored on the chip of the payment card (EMV (Europay, Mastercard, Visa) Tag 9F42), using the three-letter ISO 4217 code. Child element of `iccData`. | | `dispensedAmount` | No | Decimal | For ATM transactions: cash amount dispensed. For POS and eCommerce transactions: equivalent to `baseAmount`. | | `cardSchemeConversionDate` | No | String, format MMDD | Card scheme conversion date. | | `cardSchemeTraceID` | No | String, max 32 characters | Card scheme trace ID. Used to determine the rate at authorisation for NE2E settlement calculations. | | `authorisationCode` | No | String, 0–6 ASCII characters | Authorisation code generated by the card scheme when the transaction was authorised. Accepts ASCII values 32 through 126 (space to tilde). | | `additionalReferenceID` | No | String, max 50 characters | Supplementary transaction reference identifier. | | `additionalReferenceCode` | No | String, max 50 characters | Supplementary transaction reference code. | | `rejectionReason` | No | String | Rejection code added by Fexco in the rejections file. Do not include this element in submitted files. See [Rejection codes](#rejection-codes). | > [!NOTE] > > The three NE2E settlement fields (`schemeNE2ESettlementAmount`, > `schemeNE2ESettlementRate`, and `SchemeNE2ESettlementCurrency`) must > all be present or all be absent. Providing only one or two of the > three fields results in rejection code R04. > [!WARNING] > > Elements must appear in exactly the order shown in the table above. > For example, `authorisationCode` must come after > `customerInstructions`. Placing elements out of order causes an S3 > rejection (InvalidXml). If you include optional elements, insert > them in the position shown in the table. ## Currency precision Transaction amount fields must use the number of decimal places defined by [ISO 4217](https://www.iso.org/iso-4217-currency-codes.html) for the transaction currency. The following table lists the decimal places for currencies commonly used in DCC transactions. | Currency | Decimal places | | :- | :- | | EUR | 2 | | USD | 2 | | GBP | 2 | | AED | 2 | | MGA | 2 | | NAD | 2 | | IQD | 3 | | CLP | 0 | | JPY | 0 | | UGX | 0 | | VND | 0 | For currencies not listed above, apply the decimal places defined by ISO 4217. ## Confirmation file format Fexco generates confirmation files each time a transaction XML file is submitted. The following table describes each confirmation file. | File | Filename | Format | Description | | :- | :- | :- | :- | | Status file | `XXXYYYYMMDDhhmmssnnnnnn.status` | Plain text | Contains the status code, valid transaction count, and invalid transaction count. Not encrypted. | | Rejections file | `XXXYYYYMMDDhhmmssnnnnnn_rejections.xml.gpg` | GNU Privacy Guard (GPG)-encrypted XML | Contains each rejected transaction with a `rejectionReason` code. Generated only when the file contains rejected transactions. | ### Status file format The status file contains three lines in the following format. ``` status=S0 valid transactions=15 invalid transactions=0 ``` If the file has an `S3` status (invalid XML format), an additional line appears below the status line in the following format. ``` InvalidXml:org.xml.sax.SAXParseException; lineNumber: XX; columnNumber: XX; ERROR_DETAILS ``` ### Rejections file format The rejections file uses the same XML structure as the submitted I-file, with a `rejectionReason` element added to each rejected transaction. The rejections file is encrypted using GPG under the same Payment Card Industry Data Security Standard (PCI DSS) requirement as the submitted file. ## Status codes Fexco returns one of the following status codes in the `.status` confirmation file after processing a submitted XML I-file. | Code | Description | Action | | :- | :- | :- | | `S0` | File accepted entirely. | No action needed. | | `S1` | Unknown error occurred. | Contact Fexco DCC Support at [DCCSupport@fexco.com](mailto:DCCSupport@fexco.com). | | `S2` | File partially accepted. Some transactions were rejected. | Decrypt the rejections file. Correct the rejected transactions and resubmit them in a new file. Do not resubmit accepted transactions. Increment the sequence number for the new file. | | `S3` | File rejected entirely. Invalid XML format. | Read the `InvalidXml` line in the status file to find the error location and details. Correct the XML and resubmit with the same sequence number. | | `S4` | File rejected entirely. Duplicate file detected. | Verify the sequence number in the filename. Do not increment the sequence number. Resubmit with the correct sequence number. | | `S5` | File rejected entirely. Partial rejection is not supported for this account configuration. | Decrypt the rejections file. Correct the rejected transactions and resubmit them in a new file. Do not resubmit accepted transactions. Use the same sequence number for the new file. | ## Rejection codes Fexco includes a `rejectionReason` code in the rejections file for each rejected transaction. The following table describes each rejection code. | Code | Description | | :- | :- | | `R00` | Invalid merchant originator. The `merchantID` value is not recognized. | | `R01` | Unknown error occurred. Contact Fexco DCC Support at [DCCSupport@fexco.com](mailto:DCCSupport@fexco.com). | | `R02` | Invalid exchange rate. | | `R03` | Invalid NE2E settlement rate. This code is no longer supported. | | `R04` | Insufficient NE2E data. All three NE2E settlement fields must be provided together. | | `R05` | File prefix is not valid for the acquirer. | | `R06` | File prefix is not unique to the acquirer. | | `R07` | A unique merchant template could not be found for the acquirer and merchant type. | | `R08` | Invalid card scheme conversion date. | | `R09` | Invalid currency. | | `R10` | Transaction currency is not a three-letter alphabetic code. | | `R11` | Transaction does not contain a transaction currency. | ## Sample XML The following example shows an XML I-file with an ATM DCC transaction, a POS DCC transaction (opt-in), and a POS domestic transaction (opt-out) submitted by two merchants under the same file. The ATM transaction uses a Japanese Yen (JPY) cardholder currency (zero decimal places). The POS transactions show the difference between an accepted and a declined DCC offer. ```xml theme={null} 53023215 debit 102.00 JPY 7636 74.8629 2026-10-20T09:30:10Z magswipe 100.00 515682 debit 100.00 NZD 106.16 1.06164 2026-10-20T14:15:22Z chip 123456 515682 debit 50.00 AUD 50.00 1.00 2026-10-20T14:20:00Z chip 789012 ``` > [!TIP] > > Download a > [sample XML I-file](https://docs.fexco.com/samples/transaction-xml-i-file-sample.xml) to > see a complete working example. Use it as a starting point for your > own file. ## Scheme field mapping When building an I-file, you need to know which card scheme data elements (Visa and Mastercard) map to each I-file field. Use the mapping page for your channel: | Your channel | Mapping page | Message type | | :- | :- | :- | | POS terminals or eCommerce | [POS and eCommerce I-file field mapping](https://docs.fexco.com/dcc/developer-resources/file-formats/pos-ecommerce-ifile-field-mapping.md) | Dual message (DMS): authorisation and clearing are separate processes. | | ATMs | [ATM I-file field mapping](https://docs.fexco.com/dcc/developer-resources/file-formats/atm-ifile-field-mapping.md) | Single message (SMS): authorisation, clearing, and settlement happen in one message. | ## Next steps Use the following resources to continue after reviewing this reference. * [Build and submit an XML I-file](https://docs.fexco.com/dcc/guides/transaction-import/build-and-submit/xml-i-file.md): follow the step-by-step guide to construct, encrypt, and submit your I-file. * [How transaction import works](https://docs.fexco.com/dcc/guides/transaction-import/how-it-works.md): review the purpose of transaction import and the daily file cycle. * [Troubleshoot transaction file errors](https://docs.fexco.com/dcc/guides/transaction-import/troubleshoot.md): diagnose and resolve common submission errors. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.