Log into Pro Sandbox

This document contains details about each of the standard RDFs, including field descriptions:

  • [Customer Master](🔗)

  • [Account Card](🔗)

  • [Authorized Transactions](🔗)

  • [Posted Transactions](🔗)

  • [Lookup file](🔗)

See the <a href="doc:secondary-rdf-reference" target="_blank">Secondary RDF Reference</a> for RDFs that contain all possible RDF fields.

## Customer Master RDF

The Customer Master RDF is a list of all of your primary account holders. The first Customer Master RDF that you receive contains all of your account records. The RDFs after that contain only the new records and the changed records from the previous day.

This table contains the default fields for the Customer Master RDF. Also see [Customizing the RDFs](🔗) to see fields to add. All fields are strings unless otherwise specified.

  • The primary key for this file is `GALILEO ACCOUNT ID` + `UNIQUE PROGRAM ID`.

  • The filename format is `customermasterfile_yyyymmdd.txt`.

RDF field nameLengthDescription
`RECORD TYPE`1The type of record. `D` — Detail; `H` — Header; `T` — Trailer
`UNIQUE PROGRAM ID`15Numeric. The identifier that Galileo has assigned to your program.
`ISSUED DATE`8The date-time when the customer account was first changed to `status: N` (active). Called `start_date` in other contexts.
`ID`50The customer's ID that was used for <<glossary:KYC>>/<<glossary:CIP>>, usually the SSN. You can see an SSN only if you are PCI compliant; otherwise, you get blank spaces. See the <a href="ref:api-reference-customer-id-types" target="_blank">Customer ID Types</a> enumeration for the possible values.
`ID TYPE`5The type of identifier in the `ID` field, such as SSN or driver license. See the <a href="ref:api-reference-customer-id-types" target="_blank">Customer ID Types</a> enumeration for the possible values.
`PRIMARY CARDHOLDER'S FIRST NAME`20The customer's first name
`PRIMARY CARDHOLDER'S LAST NAME`20The customer's last name
`ADDRESS LINE 1`40The first line of the customer's primary address
`ADDRESS LINE 2`40The second line of the customer's primary address, if any.
`CITY`20The city of the customer's primary address
`STATE`2The state or province of the customer's primary address
`ZIP CODE`9The postal code of the customer's primary address
`PRIMARY PHONE NUMBER`10The phone number that the customer gave as their primary number.
`SECONDARY PHONE NUMBER`10The phone number that the customer gave as their secondary number, if any
`STATUS`5The status of the account.
`CURRENT BALANCE`13The balance of the account as of 23:59:59 on the previous day. This is the ledger balance, which is the total of all posted transactions. Pending transactions such as authorization holds are not subtracted out.
`CURRENT BALANCE SIGN`1A `+` or `-` sign to indicate whether the account balance is positive or negative.
`CREATED DATE`8The date-time when a customer first applied for an account, regardless of whether the application is approved or denied. Called `application_date` in other contexts.
`NEGATIVE BALANCE DATE`8Date on which the available balance was driven negative.
`NEGATIVE BALANCE FEE AMOUNT`13Fee assessed to an account that was driven negative.
`RELOADABLE INDICATOR`1Numeric. Boolean (`0` or `1`) to indicate whether the card is reloadable. `1` means reloadable.
`GALILEO ACCOUNT ID`30Numeric. The balance ID, which is different from the account ID (<<glossary:PRN>>). It is possible for two or more accounts to share the same balance ID.
`TYPE OF ACCOUNT`5The name given to the product, such as "Mastercard Debit" or "Visa Instant Issue."
`AVAILABLE BALANCE`13The available balance as of 23:59:59 on the previous day. This is the `CURRENT BALANCE` minus pending transactions such as authorization holds.
`AVAILABLE BALANCE SIGN`1A `+` or `-` sign to indicate whether the available balance is positive or negative.
`EXTERNAL ACCOUNT NUMBER`30An identifier that you provide for your own tracking purposes. You pass this value in the `externalAccountId` parameter of the <a href="ref:post_createaccount" target="_blank">Create Account</a> or <a href="ref:post_updateaccount" target="_blank">Update Account</a> endpoint.
`LAST TRANS DATE`8The date of the last posted transaction on this account as of 23:59:59 on the previous day, including payments, settlements, adjustments, and fees. This value does not include unsettled authorizations or pending transactions.
`DATE OF BIRTH`8Account holder date of birth.
`BILL CYCLE DAY`2Numeric. Day of the month for the billing cycle.
`LOCATION ID`20Location at which the account was created, if applicable. Value can be provided by you or by Galileo.
`AGENT USER ID`2ID of the agent who created the account.
`ID 2`50Secondary identity number, if provided, such as driver license or SSN. See the <a href="ref:api-reference-customer-id-types" target="_blank">Customer ID Types</a> enumeration for the possible values.
`ID TYPE 2`5The type of identifier in the ID 2 field, such as SSN or driver license. See the <a href="ref:api-reference-customer-id-types" target="_blank">Customer ID Types</a> enumeration for the possible values.
`PRN`12The payment reference number, a unique Galileo-generated identifier for an account.

## Account Card RDF

The Account Card RDF is a list of all cards that you have issued. The first Account Card RDF that you receive contains all of your card records. The RDFs after that contain only the new records and the changed records from the previous day.

Note

Any changes to a card record, including resetting the PIN fail count by a backend process, results in the card record being included in the differential file. Some of these changes are not reflected in the data in the RDF.

This table contains the default fields for the Account Card RDF. Also see [Customizing the RDFs](🔗) to see fields to add. All fields are strings unless otherwise specified.

  • The primary key for this file is `UNIQUE PROGRAM ID` + `CARD ID`.

  • The filename format is `accountcard_yyyymmdd.txt`.

RDF field nameLengthDescription
`RECORD TYPE`1The type of record. `D` — Detail; `H` — Header; `T` — Trailer
`UNIQUE PROGRAM ID`15Numeric. The identifier that Galileo has assigned to your program.
`GROUP ID`15Source or affiliate ID. Usually the same as `LOCATION ID` in the Customer Master RDF.
`PRODUCT ID`15Numeric. The code that is assigned to the product the card belongs to.
`GALILEO ACCOUNT ID`30Numeric. The balance ID, which is different from the account ID (<<glossary:PRN>>). It is possible for multiple accounts to share the same balance ID.
`PRN`12The payment reference number, a Galileo-generated ID for the card's account.
`EXPIRATION DATE`8The card's expiration date. If you are not PCI compliant you will receive empty spaces for this value.
`CARD STATUS`5The card status, such as `N` (active), `S` (stolen) or `C` (canceled)
`CARD IDENTIFIER`30Numeric. Sometimes called the CAD, this identifier is given to each unique card that is issued to an account. There is a one-to-one relationship between a card ID and a PAN. If you are not PCI compliant, you can use this identifier instead of the PAN.
`CARD NUMBER`16The card's PAN. If you are not PCI compliant you will get empty spaces for this value.
`TYPE OF CARD`10The branded network to which the card belongs, such as Mastercard or Visa, as well as the type of card, such as personalized or instant issue.

## Authorized Transactions RDF

The Authorized Transactions RDF contains transactions that passed through the authorization stream during the previous day. These transactions include authorization requests, AVS-only checks, reversal advices and completion advices. This RDF does not include these authorization events:

  • Mastercard Banknet merchant credits (adjustments)

  • Visa Money Transfer and ReadyLink card loads (payments)

Only a subset of the transactions in this RDF will also be included in a Posted Transactions RDF. For example, authorization reversals, AVS-only checks, and denied transactions are not in the Posted Transactions RDF because they do not settle.

### Foreign authorizations

When a transaction takes place in a country that is foreign relative to the account's country, the `AUTHORIZATION AMOUNT` is in the currency of the account. For example, if an account is located in the United States and the cardholder makes a purchase in Canada, the `AUTHORIZATION AMOUNT` is in U.S. dollars and the `TRANSACTION CURRENCY CODE` is `124` (Canadian dollar). The currency conversion is performed by the card network, and it reflects the conversion rate at the time of the authorization.

Keep in mind that some online merchants conduct business in the currency of the customer instead of the location of the merchant, depending on where the customer is located. For example, a website that is based in the U.K. could have a U.S. version of its website, and so transactions on that version would be conducted in U.S. dollars.

For examples of foreign transactions see <a href="doc:card-transaction-examples#international-transaction" target="_blank">International transaction</a> in _Card Transaction Examples_ and these scenarios:

  • <a href="page:scenario-13-international-authorization" target="_blank">Scenario 13: International Authorization</a>

  • <a href="page:scenario-14-international-reversal" target="_blank">Scenario 14: International Reversal</a>

### Authorized Transactions RDF fields

This table contains the default fields for the Authorized Transactions RDF. Also see [Customizing the RDFs](🔗) to see fields to add.

  • The primary key for this file is `UNIQUE PROGRAM ID` + `AUTHORIZATION CODE` + `NETWORK CODE`.

  • The filename format is `authorizedtransactions_yyyymmdd.txt`.

  • The **Source** column indicates where the value came from: Galileo-provided or a data element (DE) in the ISO 8583 message from the network. The actual DE number for a field may vary by network, and not all DEs are present for all networks.

  • All fields are strings unless otherwise specified.

RDF field nameSourceLengthDescription
`RECORD TYPE`Galileo1The type of record. `D` — Detail; `H` — Header; `T` — Trailer
`UNIQUE PROGRAM ID`Galileo15Numeric. The identifier that Galileo has assigned to your program.
`GALILEO ACCOUNT ID`Galileo30Numeric. The balance ID, which is different from the account ID (PRN). It is possible for two or more accounts to share the same balance ID.
`CARD IDENTIFIER`Galileo30Numeric. Sometimes called the CAD, this identifier is given to each unique card that is issued to an account. If you are not PCI compliant, you can use this identifier instead of the <<glossary:PAN>>.
`TRANSACTION DATE/TIME`Galileo17This date/time stamp identifies the time that Galileo responds to the authorization request. MMDDYYYY HH24:MM:SS
`TRANSACTION CURRENCY CODE`DE0493The currency code at the point of sale.
`ADDRESS VERIFICATION RESPONSE`Galileo1The single-character result of the <<glossary:AVS>> check that Galileo passed to the network. For more information see <a href="doc:authorization#avs-only-checks" target="_blank">AVS-only checks</a> in the _Authorization_ guide.
`AUTHORIZATION RESPONSE`DE0392The response code that you or Galileo returned to the network. See the <a href="ref:api-reference-events-authorization-response-codes" target="_blank">Authorization Response Codes</a> enumeration for possible values.
`TRANSACTION AMOUNT`DE004 times the conversion rate in DE00913The amount that you or Galileo authorized for the transaction. This amount may be different from the amount of the authorization request in the case of a partial authorization. If `AUTHORIZATION RESPONSE` is `10` or `87`, the amount is a partial authorization. This amount is in the currency of the account.
`AUTHORIZATION AMOUNT SIGN`Galileo1A `+` or `-` sign to indicate whether the amount is to be debited (`-`) or credited (`+`) to the cardholder account.
`AUTHORIZATION CODE`Galileo10Numeric. A Galileo-generated identifier for the authorization, called `auth_id` in other contexts. This ID is unique only per subnetwork, so there could be an ID collision between an authorization from Mastercard Banknet and an authorization from Visa Interlink, for example. However, there is no collision among identifiers for the Visa networks (Visa credit, Interlink, Plus). See <a href="doc:mapping-transactions-within-your-system" target="_blank">Mapping Transactions Within Your System</a> for more information.
`NETWORK CODE`Galileo1A single-letter identifier to specify the subnetwork over which the authorization request arrived. See <a href="ref:api-reference-card-authorization-network-codes" target="_blank">Network Codes</a> for possible values.
`MERCHANT NUMBER`DE04230An identifier that each network assigns to a merchant location.
`MERCHANT DESCRIPTION`DE04350Descriptive text provided by the merchant to identify the merchant name and location and sometimes the transaction type.
`MERCHANT CATEGORY CODE`DE0184The ISO 18245 four-digit identifier that specifies the type of merchant, such as ATM, gas pump, bookseller, airline, hotel, and so on.
`TRANSACTION CODE`\*Galileo15A numeric value that corresponds to the type of transaction that is being attempted.
`MERCHANT COUNTRY CODE`DE0185The ISO 3166-1 three-digit code for the country where the merchant is officially located.
`PRN`Galileo12The payment reference number, a unique Galileo-generated identifier for an account.

\* The `TRANSACTION CODE` field in the Authorized Transactions RDF does not correspond to the `TRANSACTION CODE/TYPE` field in the Posted Transactions RDF. The data in the `TRANSACTION CODE` is unique to the Authorized Transactions RDF. See the <a href="ref:api-reference-transaction-types#authorization-types" target="_blank">Authorization types</a> table in the _Transactions Types_ enumeration for the values or consult the Lookup file for the RDFs.

## Posted Transactions RDF

The Posted Transactions RDF contains every transaction that has posted to a customer account during a 24-hour period: settlements, payments, adjustments and fees. To match a settlement with its corresponding authorization, use the `AUTHORIZATION CODE` or `SOURCE ID` (which are identical for card transactions).

These types of transactions do not have corresponding entries in the Authorized Transactions RDF:

  • Adjustments

  • Most payments, except for Mastercard and Maestro loads (`PMML`, `PMMX`)

  • Visa, Green Dot, and MoneyGram card loads

  • Account transfers

  • Mastercard Banknet merchant credits

  • Most fees.

    • The authorization request amount from an ATM includes all fees.

    • ATM fees that you assess are broken out separately in the Posted Transactions RDF. The `ORIGINAL AUTH CODE` for the fee contains the `AUTHORIZATION CODE` of the original ATM authorization.

  • ACH transactions

  • Direct deposit

  • Bill pay

  • Chargebacks, second presentments, provisional credit, and arbitration

  • Charge offs

  • Force-posted settlements

  • Roundups

### Post time for completions

The timestamp for a posted transaction usually corresponds to the time Galileo posts the transaction to the cardholder account. However, in the case of completions (transaction type `C`), the completion time in the Posted Transactions RDF is the time of the completion, whereas the amount is settled later, after Galileo receives the batch settlement file.

For example, a cardholder gets a preauthorization at a gas pump for 75.00 at 09:00:01 and Galileo places a 75.00 hold on the account. The completion for 35.00 arrives through the authorization stream at 09:04:30. Galileo backs out the 75.00 and places a 35.00 hold on the account. The timestamp for the completion in the Authorized Transactions RDF and the Posted Transactions RDF is 09:04:30, but the actual settlement will be a day or so later. This later settlement is visible in the CST and Program API responses but not in the Posted Transactions RDF.

For an example of a completion at a gas pump see <a href="doc:card-transaction-examples#five-step-sequence" target="_blank"> Five-step sequence</a> in _Card Transaction Examples_ and <a href="page:scenario-2-preauthorization-with-completion" target="_blank">Scenario 2: Preauthorization with Completion</a>.

### Foreign settlements

When a foreign transaction is settled, `TRANSACTION AMOUNT` is in the currency of the account rather than the currency of the merchant. The currency conversion is performed by the card network, and it reflects the conversion rate at the time the transaction cleared, which may be a different rate than when the transaction was authorized.

See [Foreign authorizations](🔗) for more information.

### Posted Transactions RDF fields

This table contains the default fields for the Posted Transactions RDF. Also see [Customizing the RDFs](🔗) to see fields to add.

  • The primary key for this file is `UNIQUE PROGRAM ID` + `AUTHORIZATION CODE` + `TRANSACTION CODE/TYPE`.

  • The filename format is `postedtransactions_yyyymmdd.txt`.

  • The **Source** column indicates where the value came from: Galileo-provided or a data element (DE) in the ISO 8583 message from the network. The actual DE number for a field may vary by network, and not all DEs are present for all networks.

  • All fields are strings unless otherwise specified.

RDF field nameSourceLengthDescription
`RECORD TYPE`Galileo1The type of record. `D` — Detail; `H` — Header; `T` — Trailer
`UNIQUE PROGRAM ID`Galileo15Numeric. The identifier that Galileo has assigned your program.
`GALILEO ACCOUNT ID`Galileo30Numeric. The balance ID, which is different from the account ID (PRN). It is possible for two or more accounts to share the same balance ID.
`CARD IDENTIFIER`Galileo30Numeric. Sometimes called the CAD, this identifier is given to each unique card that is issued to an account. If you are not PCI compliant, you can use this identifier instead of the PAN.
`TRANSACTION DATE/TIME`Galileo17The time that Galileo responds to the authorization request. MMDDYYYY HH24:MM:SS
`TRANSACTION CODE/TYPE`Galileo10The concatenation of the activity type (`act_type`) and the transaction type (`otype`). For an explanation of transaction codes see <a href="doc:about-transactions#classifying-transactions" target="_blank">Classifying transactions</a> in the _About Transactions_ guide.
`TRANSACTION AMOUNT`Galileo13The amount that was posted to the account. In the case of a settlement, the amount may be different from its corresponding authorization amount. This amount is in the currency of the account.
`TRANSACTION AMOUNT SIGN`Galileo1A `+` or `-` sign to indicate whether the amount was debited (`-`) or credited (`+`) to the cardholder account.
`TRANSACTION CURRENCY CODE`DE0493The currency code at the point of sale, in the case of card transactions.
`AUTHORIZATION CODE`Galileo10Numeric. A Galileo-generated identifier for an authorization, called `auth_id` in other contexts. For non-network transactions, this field contains the ID for the payment, adjustment, or fee. This ID is unique only per subnetwork or transaction type (payment, adjustment, fee), so there could be an ID collision between an authorization from Mastercard Banknet and a payment, for example. See <a href="doc:mapping-transactions-within-your-system" target="_blank">Mapping Transactions Within Your System</a> for more information.
`POST DATE`Galileo8The date when Galileo posted the transaction to the customer account. MMDDYYYY
`NETWORK CODE`Galileo1A single-letter identifier to specify the subnetwork over which the authorization request arrived. This field is populated only for card transactions. See <a href="ref:api-reference-card-authorization-network-codes" target="_blank">Network Codes</a> for possible values.
`MERCHANT NUMBER`DE04230An identifier that each network assigns to a merchant location. This field is populated only for card transactions.
`MERCHANT DESCRIPTION`DE04350Descriptive text provided by the merchant to identify the merchant name and location and sometimes the transaction type. This field is populated only for card transactions.
`MERCHANT CATEGORY CODE`DE0184The ISO 18245 four-digit identifier that specifies the type of merchant, such as ATM, gas pump, bookseller, airline, hotel, and so on. This field is populated only for card transactions.
`MERCHANT COUNTRY CODE`DE0195The ISO 3166-1 three-digit code for the country where the merchant is officially located. This field is populated only for card transactions.
`INTERCHANGE FEE AMOUNT`Galileo9The amount of interchange or fee associated with this transaction. ATM fees and interchange reversals are negative; interchange earned is positive. This field is populated only for card transactions.
`EXTERNAL TRANSACTION ID`_varies_20For network transactions, the authorization identification response in DE038, which is a numeric code that Galileo returns to a merchant to verify that the transaction was authorized. This number is often printed on customer receipts. For other transactions initiated by the Program API, this is the `transactionId` of the API request. This field may be populated in other ways according to your setup and the transaction type.
`PRN`Galileo12The payment reference number, a unique Galileo-generated identifier for an account.

## Lookup file

Use the Lookup file to interpret the codes in some of the RDF fields. The Lookup file for a particular day contains only those values that are included with the other RDFs on that day, so this file will include some values on one day that it does not include on other days.

The `DESCRIPTION` field contains a short description rather than a long description, because the specific meaning for some fields is different for each Galileo client according to their setup.

The primary key for this table is `FILE TYPE` + `FIELD NAME` + `CODE`. There is no foreign key to link this file to the other RDFs. All fields are strings.

FieldLengthDescription
`RECORD TYPE`1The type of record. `D` — Detail; `H` — Header; `T` — Trailer
`FILE TYPE`1The RDF that contains the field: `A` (Authorized Transactions), `C` (Customer Master), `D` (Account Card), or `P` (Posted Transactions)
`FIELD NAME`30Name of the field in the RDF
`CODE`10Possible values for the field
`DESCRIPTION`50Description of the `CODE` value

## Customizing the RDFs

You can customize your RDFs to meet your business needs. In general, if Galileo stores a value in its databases, it can provide the value in an RDF. Galileo recommends that you customize your RDFs during preliminary setup, although you can also add and delete fields later.

Note

If you would like to include a subfield or subelement of an ISO 8583 data element, as opposed to the whole element, it will require development work to parse the subfield or subelement and include it in the RDF.

This table contains a list of fields that you might want to add to the default RDF layouts. These are fields that Galileo clients commonly add. The actual DE number for a field may vary by network, and not all DEs are present for all networks.

Field nameSourceDescriptionRDF
`POS ENTRY MODE`DE022First two characters of DE022. How the PAN was entered, such as magnetic stripe, EMV chip, or contactless. See <a href="ref:api-reference-de022-codes" target="_blank">DE022 Codes</a>.Authorized, Posted
`PIN ENTRY CAPABILITY`DE022Third character of DE022. Whether the card reader had PIN-entry capability. See <a href="ref:api-reference-de022-codes" target="_blank">DE022 Codes</a>.Authorized
`SOURCE ID`GalileoFor card transactions, the source ID is the same as the authorization ID. For other types of transactions, the source ID maps back to the original transaction, such as payment ID, adjustment ID and ACH transaction ID. This value is useful to track transactions across Galileo systems. The **ID** field in the CST corresponds to the source ID.<br><br>Keep in mind that the source ID is unique only to the transaction type or the subnetwork, so there could be a collision between a source ID for a payment and a source ID for an authorization, for example. You will need to devise a way to mark source IDs with their respective activity types. See <a href="doc:mapping-transactions-within-your-system" target="_blank">Mapping Transactions Within Your System</a> for more information.Authorized, Posted
`PRODUCT ID`GalileoIdentifier for the account's product in the Galileo system.Authorized, Posted
`LOCAL SURCHARGE AMOUNT`DE028<br>DE046 (Allpoint)Fee applied to the ATM withdrawal amount by the ATM's operator.Authorized, Posted
`REVERSAL ID`GalileoMaps back to the `original_auth_id`, `original_id`, and `prior_id` in other Galileo contexts. It contains the authorization ID of the previous authorization in a series, such as with incremental authorizations, reversals, and completions. See <a href="doc:about-transactions#linking-transactions" target="_blank">Linking transactions</a> in the _About Transactions_ guide for more information.Authorized, Posted
`MESSAGE TYPE FLAG`GalileoThe transaction type (`otype`).Authorized, Posted
`TRANSACTION DESCRIPTION`VariousThe description for the transaction as provided by various sources.Posted
`CREDIT INDICATOR`GalileoIndicates whether the transaction used credit or debit rails. `N` — PIN transaction (debit); `Y` — signature (credit)Authorized, Posted
`CASHBACK AMOUNT`GalileoThe amount of cashback that was included in the transaction.Authorized, Posted
`TRACE NUMBER`DE011An identifier for a transaction, generated by the message initiator (usually the merchant), that is included with all messages related to that transaction.Posted
`FROZEN`GalileoA Boolean to indicate whether the card is frozen. Accompanied by `LOCK START DATE` and `LOCK END DATE`.Account Card
`EXPIRED AUTH CODE`GalileoThe `AUTHORIZATION CODE` of the expired authorization that the settlement matches.Posted
`IN DE39`DE039_Mastercard only._ The response code that the network returned to the merchant during stand-in processing (STIP).Authorized Transactions
`STIP STATUS`GalileoWhether the STIP transaction was an approval or denial. `STIP` — Transaction approved; `STIP Decline` — Transaction denied.Authorized Transactions
`Domestic Card Acceptor Tax ID`PDS018U.S. tax ID of the card acceptor.Posted