Skip to main content

get-transaction

Look up a single transaction by id and return every field the server can populate, including counterparty (with postalAddress for card entries) and the open properties bag of ISO 20022 / SEPA / card audit metadata (remittance text, end-to-end / mandate / creditor ids, purpose / transaction codes, MCC, masked PAN, etc.). Use this for audit / reconciliation flows; for compact lists prefer get-transactions with a verbosity cap.

Input

FieldTypeRequiredDescription
account_idstring | nullSource account.id (from get-accounts). Optional; servers MAY require it for routing or for additional authorization checks. Default: null.
transaction_idstringTransaction id (the id field from get-transactions).
Raw JSON Schema
{
"additionalProperties": false,
"properties": {
"account_id": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Source account.id (from get-accounts). Optional; servers MAY require it for routing or for additional authorization checks."
},
"transaction_id": {
"description": "Transaction id (the `id` field from get-transactions).",
"type": "string"
}
},
"required": [
"transaction_id"
],
"type": "object"
}

Output

FieldTypeRequiredDescription
contentstringHuman-readable status message.
itemTransaction | nullThe transaction when found. Default: null.

itemTransaction

Financial transaction with date, amount and metadata. Profile of: ISO 20022 EntryDetails2, Berlin Group PSD2 transactions array element, and Open Finance card transactions (cardTransactions). One shape covers both account and card transactions. Heavily-used fields (transactionDate, counterparty, FX originalAmount / originalCurrency) sit on the top-level model; everything else — remittance text, end-to-end / mandate / creditor ids, purpose / transaction codes, MCC, masked PAN, and other ISO 20022 / Open Finance audit metadata — lives under properties as string entries (see the field for the list of known keys). Servers MAY omit any optional field and SHOULD drop unset optional keys on the wire so every row stays lean for LLM consumption; a full audit view is available via get-transaction. date carries the most relevant time-anchor for the entry: the booking date when posted, the authorisation date for pending card authorisations. This diverges from ISO 20022 / Berlin Group field naming (bookingDate) on purpose — keeping a single, always-populated date field is friendlier for LLM consumption and means pending entries don't need a fabricated booking date.

FieldTypeRequiredDescription
accountIdstringReferences the id of the Account this transaction belongs to.
amountnumberTransaction amount in the user's default currency (negative for expenses, positive for income). Clients SHOULD render this without a currency symbol unless the user has explicitly asked which currency a transaction is in.
categoryIdstring | nullCategory id (the id field from get-categories which also has category name). Default: null.
counterpartyParty | nullTyped counterparty record carrying the merchant or counterparty name and any structured detail the bank exposes (account identifier, BIC, national id, address). At minimal verbosity this is suppressed and clients fall back to description, which for most entries already embeds the counterparty name. For card transactions the merchant address (Open Finance cardAcceptorAddresstownName, country, postCode, streetName) goes on counterparty.postalAddress. Default: null.
datestringPrimary date for this transaction, ISO 8601 (YYYY-MM-DD). For booked entries (isPending absent or false) this is the date the transaction posted to the account (formerly bookingDate; profile of ISO 20022 / Berlin Group bookingDate). For pending authorisations (isPending=true) — where no booking date exists yet — this is the authorisation / point-of-sale date (Open Finance transactionDate). Always populated so clients can sort and chart by date without branching on isPending.
descriptionstringTransaction description, merchant name or recipient name
idstringUnique transaction identifier (server-scoped).
isPendingboolean | nullTrue for authorisations not yet posted to the account. Profile of Berlin Group PSD2 bookingStatus collapsed to a boolean (Booked → false / absent, Pending → true). Servers SHOULD set this to true only for pending authorisations and SHOULD omit the field on booked entries (the common case) to keep payloads lean. Clients MUST treat an absent isPending as equivalent to false. Default: null.
originalAmountnumber | nullTransaction amount in originalCurrency (negative for expenses, positive for income). Present only when originalCurrency is set. Default: null.
originalCurrencystring | nullISO 4217 currency code of the original transaction, present only when the transaction was made in a currency other than the user's default. Pair with originalAmount to recover the original amount. Default: null. Examples: "EUR", "GBP", "JPY".
originalDescriptionstring | nullRaw merchant / counterparty string as the payment rail delivered it, before any server-side cleanup or categorisation. Servers SHOULD populate this only when it differs from description; when the two would be equal, omit originalDescription so clients don't have to dedupe. Default: null.
propertiesobject | nullOpen bag of rarely-used metadata keyed by string. Servers populate whatever they have; clients tolerate any subset and any extra server-specific keys. Known keys (servers SHOULD use these names when populating the corresponding value): - remittanceInformation: free-text remittance line (SEPA RemittanceInformation/Unstructured); omit when it would duplicate description. - creditorReference: structured creditor reference, typically ISO 11649 RF-prefixed. - endToEndId: ISO 20022 cross-rail end-to-end identifier preserved across the payment chain. - maskedPan: masked card PAN; middle digits MUST be masked. - merchantCategoryCode: ISO 18245 4-digit MCC for card entries. - categoryRaw: bank-native category label upstream of categoryId. - transactionCode: ISO 20022 BankTransactionCode as domain[-family[-subFamily]] (Berlin Group convention, e.g. PMNT-RCDT-SALA). - proprietaryBankTransactionCode: bank-proprietary transaction code (e.g. PURCHASE, ATM). - mandateId: SEPA / direct-debit mandate identifier. - creditorId: SEPA Creditor Identifier (direct-debit collections). - purposeCode: ISO 20022 ExternalPurposeCode (4 letters, e.g. SALA, RENT). - entryReference: stable bank-side entry reference (Berlin Group entryReference). - additionalInformation: free-form bank-attached info that doesn't fit elsewhere. Default: null.
transactionDatestring | nullCard swipe / authorisation date for booked card entries where it differs from the posting date (Open Finance transactionDate). Servers SHOULD omit when equal to date, and MUST omit on pending entries — for those, the authorisation date is carried by date itself. Default: null.
valueDatestring | nullDate the funds become available, ISO 8601. Servers SHOULD omit when equal to date. Profile of: ISO 20022 ValueDate. Default: null.

counterpartyParty

Counterparty in a transaction or transfer. Profile of: ISO 20022 PartyIdentification135 (subset). For card transactions the counterparty is the card-accepting merchant; postalAddress then carries the Open Finance cardAcceptorAddress.

FieldTypeRequiredDescription
accountIdentifierIbanIdentifier | BbanIdentifier | AccountNumberIdentifier | AliasIdentifier | nullParty's account identifier when known. Default: null.
bicstring | nullBIC / SWIFT code of the party's bank, ISO 9362. Default: null. Examples: "NWBKGB2L".
brandNamestring | nullBrand or chain name the party belongs to, when name is a specific outlet of a larger brand. For card transactions this is the merchant's parent brand (e.g. name = "Starbucks Reserve Roastery", brandName = "Starbucks"). Clients MAY use brandName to group transactions by chain while still displaying the specific outlet on each row. Default: null. Examples: "Starbucks", "Bónus".
latitudenumber | nullGeographic latitude of the party's location in decimal degrees (WGS 84). For card transactions, this is the merchant / card-acceptor location. Profile of: Berlin Group geoLocation (latitude component). Default: null. Examples: 48.8566, 64.1466.
longitudenumber | nullGeographic longitude of the party's location in decimal degrees (WGS 84). For card transactions, this is the merchant / card-acceptor location. Profile of: Berlin Group geoLocation (longitude component). Default: null. Examples: 2.3522, -21.9426.
namestringParty's full name or business name.
nationalIdNationalId | nullParty's national identifier when known. Default: null.
postalAddressPostalAddress | nullPostal address of the party. For card transactions, this is the merchant / card-acceptor address (Open Finance cardAcceptorAddress). Servers SHOULD populate whatever subset they have, typically at least townName and country. Default: null.
accountIdentifiertype: "iban"

IBAN-routed account, ISO 13616.

FieldTypeRequiredDescription
ibanstringIBAN, ISO 13616. Examples: "GB29NWBK60161331926819", "DE89370400440532013000". Pattern: ^[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}$.
typestringDiscriminator: iban. Default: "iban".
accountIdentifiertype: "bban"

Domestic Basic Bank Account Number, used in markets without an IBAN.

FieldTypeRequiredDescription
bbanstringDomestic account identifier in the country's native format. Examples: "0133-26-007890".
countrystringISO 3166-1 alpha-2 country code. Examples: "IS", "GB". Pattern: ^[A-Z]{2}$.
typestringDiscriminator: bban. Default: "bban".
accountIdentifiertype: "accountNumber"

Country-specific composite for non-IBAN markets (US, UK pre-IBAN, etc.).

FieldTypeRequiredDescription
accountNumberstringAccount number in the country's native format.
countrystringISO 3166-1 alpha-2 country code. Examples: "US", "GB". Pattern: ^[A-Z]{2}$.
routingstring | nullUS ABA routing number, when applicable. Default: null.
sortCodestring | nullUK sort code, when applicable. Default: null.
typestringDiscriminator: accountNumber. Default: "accountNumber".
accountIdentifiertype: "alias"

Alias-based identifier (UPI VPA, Pix key, email-routed payments, etc.).

FieldTypeRequiredDescription
aliasstringThe alias value as the user knows it. Examples: "alex@upi", "+44-7700-900000".
aliasType"email" | "phone" | "vpa" | "pix" | "other"Kind of alias.
typestringDiscriminator: alias. Default: "alias".
nationalIdNationalId

Person or business national identifier.

FieldTypeRequiredDescription
countrystringISO 3166-1 alpha-2 country code. Examples: "IS", "US". Pattern: ^[A-Z]{2}$.
type"ssn" | "kennitala" | "cpr" | "personnummer" | "cpf" | "other" | nullHint for the kind of identifier. bank2ai does not validate the value. Default: null.
valuestringNational identifier value, in the country's native format. Examples: "010190-1234", "123-45-6789".
postalAddressPostalAddress

Postal address of a party or card-acceptor merchant. Profile of: ISO 20022 PostalAddress24 (subset). Aligns with the Open Finance / Berlin Group cardAcceptorAddress structure so card transactions can surface where the swipe happened. Servers SHOULD populate whichever subfields the bank exposes and omit the rest; townName and country are the most commonly available and the most useful for LLM context.

FieldTypeRequiredDescription
addressLinearray<string> | nullFree-form address lines, used when the bank exposes the address as unparsed text. Servers SHOULD prefer the typed fields above and fall back to addressLine only when they cannot decompose the address. Default: null.
buildingNumberstring | nullBuilding number on the street. Default: null. Examples: "12", "12B".
countrystring | nullISO 3166-1 alpha-2 country code. Default: null. Examples: "FR", "SE", "IS", "US".
countrySubDivisionstring | nullState, province, region, or other top-level subdivision. Default: null. Examples: "CA", "Île-de-France".
postCodestring | nullPostal / ZIP code. Default: null. Examples: "75001", "SW1A 1AA".
streetNamestring | nullStreet name without the building number. Default: null. Examples: "Rue de Rivoli".
townNamestring | nullCity, town, or village name. Default: null. Examples: "Paris", "Stockholm", "Reykjavík".
Raw JSON Schema
{
"description": "Result of looking up a single transaction by id.\n\nReturned by the `get-transaction` tool. The envelope mirrors the\nrecoverable-error pattern used elsewhere in bank2ai: when the\ntransaction is found `item` is populated and `content` is a brief\nstatus message; when it isn't, `item` is omitted and `content`\nexplains why.",
"properties": {
"content": {
"description": "Human-readable status message.",
"type": "string"
},
"item": {
"anyOf": [
{
"description": "Financial transaction with date, amount and metadata.\n\nProfile of: ISO 20022 `EntryDetails2`, Berlin Group PSD2\n`transactions` array element, and Open Finance card transactions\n(`cardTransactions`). One shape covers both account and card\ntransactions. Heavily-used fields (`transactionDate`, `counterparty`,\nFX `originalAmount` / `originalCurrency`) sit on the top-level\nmodel; everything else — remittance text, end-to-end / mandate /\ncreditor ids, purpose / transaction codes, MCC, masked PAN, and\nother ISO 20022 / Open Finance audit metadata — lives under\n`properties` as string entries (see the field for the list of\nknown keys). Servers MAY omit any optional field and SHOULD drop\nunset optional keys on the wire so every row stays lean for LLM\nconsumption; a full audit view is available via `get-transaction`.\n\n`date` carries the most relevant time-anchor for the entry: the\nbooking date when posted, the authorisation date for pending\ncard authorisations. This diverges from ISO 20022 / Berlin Group\nfield naming (`bookingDate`) on purpose — keeping a single,\nalways-populated date field is friendlier for LLM consumption and\nmeans pending entries don't need a fabricated booking date.",
"properties": {
"accountId": {
"description": "References the `id` of the `Account` this transaction belongs to.",
"type": "string"
},
"amount": {
"description": "Transaction amount in the user's default currency (negative for expenses, positive for income). Clients SHOULD render this without a currency symbol unless the user has explicitly asked which currency a transaction is in.",
"type": "number"
},
"categoryId": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Category id (the `id` field from get-categories which also has category name)."
},
"counterparty": {
"anyOf": [
{
"description": "Counterparty in a transaction or transfer.\n\nProfile of: ISO 20022 `PartyIdentification135` (subset). For card\ntransactions the counterparty is the card-accepting merchant;\n`postalAddress` then carries the Open Finance `cardAcceptorAddress`.",
"properties": {
"accountIdentifier": {
"anyOf": [
{
"description": "Discriminated union of typed account identifiers. Profile of: ISO 20022 `AccountIdentification4Choice`.",
"oneOf": [
{
"description": "IBAN-routed account, ISO 13616.",
"properties": {
"iban": {
"description": "IBAN, ISO 13616.",
"examples": [
"GB29NWBK60161331926819",
"DE89370400440532013000"
],
"pattern": "^[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}$",
"type": "string"
},
"type": {
"const": "iban",
"default": "iban",
"description": "Discriminator: `iban`.",
"type": "string"
}
},
"required": [
"iban"
],
"type": "object"
},
{
"description": "Domestic Basic Bank Account Number, used in markets without an IBAN.",
"properties": {
"bban": {
"description": "Domestic account identifier in the country's native format.",
"examples": [
"0133-26-007890"
],
"type": "string"
},
"country": {
"description": "ISO 3166-1 alpha-2 country code.",
"examples": [
"IS",
"GB"
],
"pattern": "^[A-Z]{2}$",
"type": "string"
},
"type": {
"const": "bban",
"default": "bban",
"description": "Discriminator: `bban`.",
"type": "string"
}
},
"required": [
"bban",
"country"
],
"type": "object"
},
{
"description": "Country-specific composite for non-IBAN markets (US, UK pre-IBAN, etc.).",
"properties": {
"accountNumber": {
"description": "Account number in the country's native format.",
"type": "string"
},
"country": {
"description": "ISO 3166-1 alpha-2 country code.",
"examples": [
"US",
"GB"
],
"pattern": "^[A-Z]{2}$",
"type": "string"
},
"routing": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "US ABA routing number, when applicable."
},
"sortCode": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "UK sort code, when applicable."
},
"type": {
"const": "accountNumber",
"default": "accountNumber",
"description": "Discriminator: `accountNumber`.",
"type": "string"
}
},
"required": [
"accountNumber",
"country"
],
"type": "object"
},
{
"description": "Alias-based identifier (UPI VPA, Pix key, email-routed payments, etc.).",
"properties": {
"alias": {
"description": "The alias value as the user knows it.",
"examples": [
"alex@upi",
"+44-7700-900000"
],
"type": "string"
},
"aliasType": {
"description": "Kind of alias.",
"enum": [
"email",
"phone",
"vpa",
"pix",
"other"
],
"type": "string"
},
"type": {
"const": "alias",
"default": "alias",
"description": "Discriminator: `alias`.",
"type": "string"
}
},
"required": [
"alias",
"aliasType"
],
"type": "object"
}
]
},
{
"type": "null"
}
],
"default": null,
"description": "Party's account identifier when known."
},
"bic": {
"anyOf": [
{
"pattern": "^[A-Z]{6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3})?$",
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "BIC / SWIFT code of the party's bank, ISO 9362.",
"examples": [
"NWBKGB2L"
]
},
"brandName": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Brand or chain name the party belongs to, when `name` is a specific outlet of a larger brand. For card transactions this is the merchant's parent brand (e.g. `name` = \"Starbucks Reserve Roastery\", `brandName` = \"Starbucks\"). Clients MAY use `brandName` to group transactions by chain while still displaying the specific outlet on each row.",
"examples": [
"Starbucks",
"Bónus"
]
},
"latitude": {
"anyOf": [
{
"maximum": 90,
"minimum": -90,
"type": "number"
},
{
"type": "null"
}
],
"default": null,
"description": "Geographic latitude of the party's location in decimal degrees (WGS 84). For card transactions, this is the merchant / card-acceptor location. Profile of: Berlin Group `geoLocation` (latitude component).",
"examples": [
48.8566,
64.1466
]
},
"longitude": {
"anyOf": [
{
"maximum": 180,
"minimum": -180,
"type": "number"
},
{
"type": "null"
}
],
"default": null,
"description": "Geographic longitude of the party's location in decimal degrees (WGS 84). For card transactions, this is the merchant / card-acceptor location. Profile of: Berlin Group `geoLocation` (longitude component).",
"examples": [
2.3522,
-21.9426
]
},
"name": {
"description": "Party's full name or business name.",
"type": "string"
},
"nationalId": {
"anyOf": [
{
"description": "Person or business national identifier.",
"properties": {
"country": {
"description": "ISO 3166-1 alpha-2 country code.",
"examples": [
"IS",
"US"
],
"pattern": "^[A-Z]{2}$",
"type": "string"
},
"type": {
"anyOf": [
{
"description": "Opaque label for the kind of national identifier carried in `NationalId.value`.\n\nbank2ai does not validate national-ID formats; this is a hint so\nclients can render or route appropriately. Servers SHOULD set the\nclosest-matching value or use `other`.",
"enum": [
"ssn",
"kennitala",
"cpr",
"personnummer",
"cpf",
"other"
],
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Hint for the kind of identifier. bank2ai does not validate the value."
},
"value": {
"description": "National identifier value, in the country's native format.",
"examples": [
"010190-1234",
"123-45-6789"
],
"type": "string"
}
},
"required": [
"value",
"country"
],
"type": "object"
},
{
"type": "null"
}
],
"default": null,
"description": "Party's national identifier when known."
},
"postalAddress": {
"anyOf": [
{
"description": "Postal address of a party or card-acceptor merchant.\n\nProfile of: ISO 20022 `PostalAddress24` (subset). Aligns with the\nOpen Finance / Berlin Group `cardAcceptorAddress` structure so card\ntransactions can surface where the swipe happened. Servers SHOULD\npopulate whichever subfields the bank exposes and omit the rest;\n`townName` and `country` are the most commonly available and the\nmost useful for LLM context.",
"properties": {
"addressLine": {
"anyOf": [
{
"items": {
"type": "string"
},
"type": "array"
},
{
"type": "null"
}
],
"default": null,
"description": "Free-form address lines, used when the bank exposes the address as unparsed text. Servers SHOULD prefer the typed fields above and fall back to `addressLine` only when they cannot decompose the address."
},
"buildingNumber": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Building number on the street.",
"examples": [
"12",
"12B"
]
},
"country": {
"anyOf": [
{
"pattern": "^[A-Z]{2}$",
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "ISO 3166-1 alpha-2 country code.",
"examples": [
"FR",
"SE",
"IS",
"US"
]
},
"countrySubDivision": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "State, province, region, or other top-level subdivision.",
"examples": [
"CA",
"Île-de-France"
]
},
"postCode": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Postal / ZIP code.",
"examples": [
"75001",
"SW1A 1AA"
]
},
"streetName": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Street name without the building number.",
"examples": [
"Rue de Rivoli"
]
},
"townName": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "City, town, or village name.",
"examples": [
"Paris",
"Stockholm",
"Reykjavík"
]
}
},
"type": "object"
},
{
"type": "null"
}
],
"default": null,
"description": "Postal address of the party. For card transactions, this is the merchant / card-acceptor address (Open Finance `cardAcceptorAddress`). Servers SHOULD populate whatever subset they have, typically at least `townName` and `country`."
}
},
"required": [
"name"
],
"type": "object"
},
{
"type": "null"
}
],
"default": null,
"description": "Typed counterparty record carrying the merchant or counterparty name and any structured detail the bank exposes (account identifier, BIC, national id, address). At `minimal` verbosity this is suppressed and clients fall back to `description`, which for most entries already embeds the counterparty name. For card transactions the merchant address (Open Finance `cardAcceptorAddress` — `townName`, `country`, `postCode`, `streetName`) goes on `counterparty.postalAddress`."
},
"date": {
"description": "Primary date for this transaction, ISO 8601 (YYYY-MM-DD). For booked entries (`isPending` absent or false) this is the date the transaction posted to the account (formerly `bookingDate`; profile of ISO 20022 / Berlin Group `bookingDate`). For pending authorisations (`isPending=true`) — where no booking date exists yet — this is the authorisation / point-of-sale date (Open Finance `transactionDate`). Always populated so clients can sort and chart by `date` without branching on `isPending`.",
"format": "date",
"type": "string"
},
"description": {
"description": "Transaction description, merchant name or recipient name",
"type": "string"
},
"id": {
"description": "Unique transaction identifier (server-scoped).",
"type": "string"
},
"isPending": {
"anyOf": [
{
"type": "boolean"
},
{
"type": "null"
}
],
"default": null,
"description": "True for authorisations not yet posted to the account. Profile of Berlin Group PSD2 `bookingStatus` collapsed to a boolean (Booked → false / absent, Pending → true). Servers SHOULD set this to true only for pending authorisations and SHOULD omit the field on booked entries (the common case) to keep payloads lean. Clients MUST treat an absent `isPending` as equivalent to false."
},
"originalAmount": {
"anyOf": [
{
"type": "number"
},
{
"type": "null"
}
],
"default": null,
"description": "Transaction amount in `originalCurrency` (negative for expenses, positive for income). Present only when `originalCurrency` is set."
},
"originalCurrency": {
"anyOf": [
{
"pattern": "^[A-Z]{3}$",
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "ISO 4217 currency code of the original transaction, present only when the transaction was made in a currency other than the user's default. Pair with `originalAmount` to recover the original amount.",
"examples": [
"EUR",
"GBP",
"JPY"
]
},
"originalDescription": {
"anyOf": [
{
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Raw merchant / counterparty string as the payment rail delivered it, before any server-side cleanup or categorisation. Servers SHOULD populate this only when it differs from `description`; when the two would be equal, omit `originalDescription` so clients don't have to dedupe."
},
"properties": {
"anyOf": [
{
"additionalProperties": {
"type": "string"
},
"type": "object"
},
{
"type": "null"
}
],
"default": null,
"description": "Open bag of rarely-used metadata keyed by string. Servers populate whatever they have; clients tolerate any subset and any extra server-specific keys. Known keys (servers SHOULD use these names when populating the corresponding value):\n- `remittanceInformation`: free-text remittance line (SEPA `RemittanceInformation/Unstructured`); omit when it would duplicate `description`.\n- `creditorReference`: structured creditor reference, typically ISO 11649 RF-prefixed.\n- `endToEndId`: ISO 20022 cross-rail end-to-end identifier preserved across the payment chain.\n- `maskedPan`: masked card PAN; middle digits MUST be masked.\n- `merchantCategoryCode`: ISO 18245 4-digit MCC for card entries.\n- `categoryRaw`: bank-native category label upstream of `categoryId`.\n- `transactionCode`: ISO 20022 BankTransactionCode as `domain[-family[-subFamily]]` (Berlin Group convention, e.g. `PMNT-RCDT-SALA`).\n- `proprietaryBankTransactionCode`: bank-proprietary transaction code (e.g. `PURCHASE`, `ATM`).\n- `mandateId`: SEPA / direct-debit mandate identifier.\n- `creditorId`: SEPA Creditor Identifier (direct-debit collections).\n- `purposeCode`: ISO 20022 ExternalPurposeCode (4 letters, e.g. `SALA`, `RENT`).\n- `entryReference`: stable bank-side entry reference (Berlin Group `entryReference`).\n- `additionalInformation`: free-form bank-attached info that doesn't fit elsewhere."
},
"transactionDate": {
"anyOf": [
{
"format": "date",
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Card swipe / authorisation date for booked card entries where it differs from the posting `date` (Open Finance `transactionDate`). Servers SHOULD omit when equal to `date`, and MUST omit on pending entries — for those, the authorisation date is carried by `date` itself."
},
"valueDate": {
"anyOf": [
{
"format": "date",
"type": "string"
},
{
"type": "null"
}
],
"default": null,
"description": "Date the funds become available, ISO 8601. Servers SHOULD omit when equal to `date`. Profile of: ISO 20022 `ValueDate`."
}
},
"required": [
"id",
"accountId",
"description",
"amount",
"date"
],
"type": "object"
},
{
"type": "null"
}
],
"default": null,
"description": "The transaction when found."
}
},
"required": [
"content"
],
"type": "object"
}