Accounts

Current and savings accounts, their balances, their holders and their transactions
View as Markdown

Where it lives: at accounts in the Financial Position, and on its own from the accounts endpoint.

The account is the centre of a banking extraction: it carries the balances, and it carries the movements that everything else is inferred from — income, rent, recurring commitments, unusual activity.

idstringRequiredformat: "object-id"
product"financial_account"Required
sub_family"financial_account:current"Required
fetch_datestringRequiredformat: "datetime"
Date this product was fetched
data_enrichmentenumRequired
Data enrichment status. Indicates whether the product has been enriched with additional data. If not, the product will be filled with generic data.
Allowed values:
identifierobjectRequired
Account identifier
customer_segmentenumRequired
product_namestringRequired
Product name
product_aliasstringOptional
Product alias
product_descriptionstringOptional
Product Description
opening_datedateOptional
Account opening date
transactionslist of objectsOptional
Account transactions
holderslist of objectsOptional
Account holders
availableobjectOptionalDeprecated
The total accessible funds, considering all cleared and uncleared transactions. This represents the amount a user can use or withdraw immediately.
bookedobjectOptionalDeprecated
The net monetary amount without considering pending transactions. It reflects the actual balance at any given moment.

Two balances, and they are not interchangeable

  • booked — the settled balance: what has actually cleared. This is the figure the institution shows as “balance”.
  • available — what can be spent right now: the booked balance adjusted for pending movements and any credit line attached to the account.

For solvency, booked is the honest number. For “can this payment go through today”, available is.

Holders

Who the account belongs to, and in what capacity — the difference between a sole account and one held with somebody else, which matters for both affordability and identity checks.

roleenumRequired
Holder Role
Allowed values:
namestringOptional
Holder name
identifierobjectOptional
Holder identifier
current_customerbooleanOptional
Is current customer?

Transactions

Transactions are only retrieved when the feature is configured to read them (read_transactions, with a date range). Each one carries its dates, its amount, the running balance after it, and the parties involved.

typeenumRequired
Transaction type
statusenumRequired
Transaction status
categoryenumRequired
Transaction category. Transactions are classified based on their context and nature. The categorization is only applied if data enrichment is enabled for your current application. Otherwise, this field will be filled with a generic category based on the transaction amount. Contact support for more information.
operation_datedateOptional
value_datedateOptional
amountobjectOptional
Transaction amount
balanceobjectOptional
Account balance after the transaction
descriptionslist of stringsOptional
Original transaction descriptions
provider_idstringOptional
Unique ID for the transaction in the provider system
referencestringOptional
Transaction reference
payeeobjectOptional
Payee information, if available
payerobjectOptional
Payer information, if available
merchantobjectOptional
Merchant information, if available

Every transaction arrives categorised

category is a two-level classification applied on top of what the bank published, in a fixed vocabulary — income::income::salary & payroll, expenses::household::rent, expenses::transport::car & fuel. It is what lets you compute income, fixed commitments and discretionary spending without writing a rules engine of your own.

The prefix is the first thing to branch on: income::, expenses:: or null:: for movements that are neither (internal transfers, card adjustments). Anything the classifier could not place lands in …::to categorize::unclassified rather than being guessed at.

Type and status

How far back the transactions go is decided by two things: the range you asked for in the feature’s configuration, and what the institution itself keeps. The engine’s engine_restrictions state its limit — ask for more and the execution is rejected, unless you set limits_behaviour: adapt.