Data models

These shared shapes are referenced from tool inputs and outputs. Servers MAY return additional fields; clients MUST tolerate unknown fields.

Model	Description
Account	Bank account with balance and metadata. Property names follow Berlin Group PSD2 accountDetails where they overlap (iban, bban, bic, maskedPan, product, status, usage), so servers fronting a PSD2 backend can map fields directly. Servers SHOULD populate at least one of accountNumber, iban, bban, or maskedPan.
Category	Transaction category for spending classification. bank2ai-defined categorization model; not profiled from a single upstream standard. Localized names live on this object so clients can render category labels per the user's locale; programmatic identity goes through id. See CANONICAL_CATEGORY_IDS for the recommended id values shared across servers.
Recipient	Saved payment recipient. Profile of: ISO 20022 Creditor and CreditorAccount (subset). Account routing goes through the typed accountIdentifier discriminated union (IBAN, BBAN, country-specific account number, or alias); national identification is opaque to bank2ai and lives in the typed nationalId sub-object.
Transaction	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.