Skip to navigation
Data models

Data models

What a Financial Rider session returns, field by field
View as Markdown

A Financial Rider session reads your customer’s banks, and what it returns is their financial position: the customer profile and one list per banking family you asked for. A family you did not ask for is absent. These pages lay each model out flat, field by field, rendered from the live API specification.

Where the data arrives

The same models reach you by two routes:

  • Get Session Results — whenever you ask, behind your application secret.
  • The financial-rider:ended webhook — when the session ends, encrypted with the session’s aes_key. Without one, the event carries no data and tells you to fetch it. Webhooks has the details.

With recurring access, every later read is a direct execution of its own, and its results come back in these same models.

The financial position

customerobjectOptional
Customer family
accountslist of objectsOptional
Current accounts
cardslist of objectsOptional
Cards
depositslist of objectsOptional
Deposits
investmentsobjectOptional
Investments family
loanslist of objectsOptional
Loans
direct_debitslist of objectsOptional
Direct debits
Customer profile

Your customer’s identity as the first connected bank knows it.

Banking

The whole family at a glance, and the envelope every banking product shares.

Accounts

Current and savings accounts, their balances, their holders and their transactions.

Cards

Debit, credit and prepaid cards, with their limits and their movements.

Loans & mortgages

What your customer owes the bank, and what it costs them every month.

Deposits & savings

Money set aside — for a term, or for a purpose.

Investments

Securities accounts, stocks, funds and private pension plans.

Direct debits

The standing charges against an account — who charges, how much, how often.

Attachments

The documents a bank delivers with a record, such as the receipt of a direct debit’s last charge.

The session envelope

The position travels as data inside the session results, beside the connections that finished, the consent your customer gave and the messages the session raised:

is_closedbooleanRequired

Whether the session is over. false means these are the results gathered so far, and more may come.

status_codeenumRequired
The status of the session.
cursorenumRequired
The last screen the end user reached.
Allowed values:
connectionsmap from strings to stringsRequired

The entities that connected, by execution id, with the engine that read each one. Only connections that finished are listed; with tokenized_access, these are the ids to exchange the ticket with.

consentobjectOptional
What the end user consented to, and the proof of it. Absent when the session showed no consent screen.
retrieved_featureslist of enumsOptional
The features some connection actually delivered.
dataobjectOptional

Everything the connections read, merged into one financial position. Absent when the session ended without results: cancelled by the end user, failed or timed out.

messageslist of objectsOptionalDefaults to []

What the session has to say about itself and about the data it read, oldest first. Most sessions say nothing. A situation is reported once however many times it occurred: automate on message_id, and treat message as text for a person.