Build and submit an XML I-file

The XML I-file is the transaction file format used by ATM operators, acquirers, and payment service providers (PSPs) to report daily DCC and domestic transactions to Fexco. You build an XML file containing all card transactions for the reporting period, encrypt it with GPG, upload it to Fexco’s SFTP server, and then check the confirmation files to verify the result.

Before you start

You need the following before you build and submit an XML I-file:

SFTP credentials and GPG encryption keys, configured through security setup.
A three-character filename prefix assigned by Fexco during onboarding.
The I-file XSD schema file for validation, provided by Fexco during onboarding.
Boarded merchants with merchant IDs that match the IDs in your file.

If you do not have your filename prefix, SFTP location, or XSD file, contact Fexco DCC Support at DCCSupport@fexco.com.

File naming convention

Name your XML I-file using the following format:

XXXYYYYMMDDhhmmssnnnnnn.XML

The components of this filename are described in the following table.

Component	Description
`XXX`	Three-character filename prefix assigned by Fexco. If the prefix contains a letter, it must be uppercase.
`YYYYMMDDhhmmss`	File creation timestamp. `YYYY` = year, `MM` = month, `DD` = day, `hh` = hour, `mm` = minute, `ss` = second.
`nnnnnn`	Six-digit file sequence number, zero-padded (for example, `000001`). See the sequence number rules below.
`.XML`	File extension (uppercase).

For example:

JLB20261020143000000217.XML

Sequence number rules

The six-digit sequence number tracks the order of your file submissions. Follow these rules:

Start at 000001 for your first file.
Increment by 1 for each file that Fexco accepts (status S0 or S2).
Do not increment if the previous file was rejected entirely (status S3, S4, or S5). Resubmit the corrected file with the same sequence number.
The sequence number must be zero-padded to six digits (for example, 000001, not 1).
Reusing a sequence number that was already accepted causes the file to be rejected as a duplicate (status S4).

Build the XML file

Follow the steps below to structure your XML file, add merchants and devices, and populate the transaction records:

Create the root element

Start with the XML declaration and the iFile root element. Set the schemaVersion attribute to the version of the XSD you are validating against.

<?xml version="1.0" encoding="UTF-8"?>
<iFile xmlns="http://www.fexco.com" schemaVersion="25.2.0">

  <!-- merchants and transactions go here -->

</iFile>

The iFile root element also accepts an optional disposition attribute. Set it to test during development or production for live files.

Use the default namespace declaration exactly as shown above (xmlns="http://www.fexco.com"). Do not use namespace prefixes such as ns0:. Some XML libraries add prefixes automatically, which can cause the file to be rejected with status S3 (InvalidXml). If your library adds a prefix, configure it to use the default namespace instead.

Add a merchant

Each merchant element, groups the transactions for one merchant ID. The merchantID attribute must match the merchant originator value assigned during merchant boarding.

<merchant merchantID="1702914718212">
  <!-- terminals and transactions go here -->
</merchant>

The only required attribute is merchantID, a unique alphanumeric identifier (1–16 characters). For the full list of optional merchant attributes, see the XML I-file reference.

Add terminals, ATMs, or e-commerce channels

Inside each merchant, add one or more terminal, atm, or eComm elements depending on where the transactions occurred. Each device or channel element groups the transactions for that specific device.

POS terminal
ATM
E-commerce

<terminal terminalID="ABC90" batchNumber="1">
  <!-- transactions go here -->
</terminal>

<atm atmID="BW7I2006" batchNumber="50">
  <!-- transactions go here -->
</atm>

<eComm eCommID="Monc202A808" batchNumber="53">
  <!-- transactions go here -->
</eComm>

Each device element has the following attributes:

Attribute	Required	Description
`terminalID` / `atmID` / `eCommID`	Yes	Unique alphanumeric identifier for the device or channel (1-11 characters).
`batchNumber`	No	Batch sequence number (0-999, rolls over). If not used, specify `0`.

Add transactions

Inside each terminal, atm, or eComm element, add one transaction element per card transaction. The following example shows a POS DCC transaction where a cardholder paid in NZD at an AUD-base merchant:

<terminal terminalID="ABC90" batchNumber="1">
  <transaction
    transactionID="6843379070056369304008"
    rateOfferRef="eb73fc8c-4c4c-4e6d-9a55-334c5335ea43"
    currencyConversionType="dcc"
    disposition="production">

    <bin>515682</bin>
    <transactionCode>debit</transactionCode>
    <baseAmount>100.00</baseAmount>
    <transactionCurrency>NZD</transactionCurrency>
    <transactionAmount>106.16</transactionAmount>
    <exchangeRate>1.06164</exchangeRate>
    <transactionDateTime>2026-10-20T09:30:10Z</transactionDateTime>
    <customerInstructions>chip</customerInstructions>
    <authorisationCode>123456</authorisationCode>

  </transaction>
</terminal>

The mandatory transaction elements must appear in the order shown. For the full list of mandatory, optional, and attribute fields, see the XML I-file reference.The following example shows a transaction where the cardholder declined DCC (opted out). The transaction is processed in the merchant’s base currency, so transactionCurrency matches the base currency, transactionAmount equals baseAmount, and exchangeRate is 1.00.

<terminal terminalID="ABC90" batchNumber="1">
  <transaction
    transactionID="6843379070056369304009"
    currencyConversionType="dcc"
    disposition="production">

    <bin>515682</bin>
    <transactionCode>debit</transactionCode>
    <baseAmount>100.00</baseAmount>
    <transactionCurrency>AUD</transactionCurrency>
    <transactionAmount>100.00</transactionAmount>
    <exchangeRate>1.00</exchangeRate>
    <transactionDateTime>2026-10-20T09:35:00Z</transactionDateTime>
    <customerInstructions>chip</customerInstructions>
    <authorisationCode>654321</authorisationCode>

  </transaction>
</terminal>

For a full comparison of opt-in and opt-out field values, see Transaction inclusion and exclusion rules.

Download a sample XML I-file to see a complete working example with a DCC transaction and a domestic transaction. Use it as a starting point for your own file.

Encrypt and submit the file

Follow the steps below to validate, encrypt, and upload your file to Fexco:

Validate against the XSD

Validate the completed XML file against the I-file XSD schema before submission. Files that do not conform to the schema are rejected entirely (status S3).Use the validator below to check your file for structural errors before submitting it to Fexco:

Encrypt with GPG

As a PCI DSS requirement, encrypt the XML file using GPG with the encryption key provided by Fexco. The encrypted file must use the .gpg suffix in lowercase.

JLB20261020143000000217.XML.gpg

Upload to SFTP

Upload the encrypted file to the Incoming folder on the Fexco SFTP server.

If you are submitting multiple files on the same day, wait for the confirmation file from the previous submission before uploading the next file.

Check the confirmation files

After Fexco processes your file, two confirmation files appear in the Outgoing folder on your SFTP server. The following table describes each file:

File	Filename	Description
Status file	`XXXYYYYMMDDhhmmssnnnnnn.status`	A plain-text file with the status code, valid transaction count, and invalid transaction count.
Rejections file	`XXXYYYYMMDDhhmmssnnnnnn_rejections.xml.gpg`	A GPG-encrypted XML file listing each rejected transaction with a `rejectionReason` code. Only generated when the file contains rejected transactions.

Read the status file

Open the .status file to check the result. A successful submission looks like this:

status=S0
valid transactions=15
invalid transactions=0

The status file shows S0 and invalid transactions=0. If the status is S2 or higher, see the XML I-file status codes reference for the full list of codes and what action to take for each one.

Common causes of S3 (InvalidXml)

If the file is rejected entirely with status S3, the most common causes are:

Elements in the wrong order (for example, authorisationCode before customerInstructions).
A namespace prefix such as ns0: on the root element instead of the default namespace.
A missing or incorrect schemaVersion attribute.
Unterminated or malformed XML tags.
An encoding declaration that does not match the file content.

Use the line number and column number in the InvalidXml status line to locate the error.

Handle rejected transactions

If the status is S2 or S5, decrypt the rejections file to see which transactions failed and why. Each rejected transaction includes a rejectionReason code (for example, R00 for an unrecognized merchantID, R02 for an invalid exchange rate, or R04 for incomplete NE2E data). Correct the rejected transactions and resubmit them in a new file. Do not include transactions that were already accepted. For the full list of rejection codes, see XML I-file status codes.

Next steps

After you have submitted your XML I-file and verified the confirmation, use the following resources for troubleshooting or to learn more about the transaction import process:

XML I-file reference: look up the full XSD schema source and field specifications.
How transaction import works: review the purpose of transaction import and the daily file cycle.
Choose a file format: compare XML I-file, I-file, and V-file to confirm you are using the right format.

Getting started

Merchant boarding

Rate service

Transaction import

Android app

Go live

Before you start

File naming convention

Sequence number rules

Build the XML file

Create the root element

Add a merchant

Add terminals, ATMs, or e-commerce channels

Add transactions

Encrypt and submit the file

Validate against the XSD

Encrypt with GPG

Upload to SFTP

Check the confirmation files

Read the status file

Common causes of S3 (InvalidXml)

Handle rejected transactions

Next steps