Features

A Financial Rider session reads the features you name in settings.executions_features when you create it: each one is a family of your customer’s finances, read from every bank they connect, and what the banks return is merged into one Financial Position. The feature model itself — the same codes in every product — is in Features, in Platform.

What a session can read

Any other feature code is refused when the session is created: 422, on its position in executions_features.

Asking for them

Name a feature by its code, or as an object when you configure it — and mix both forms in one list:

{
  "settings": {
    "executions_features": [
      "customer_information_read",
      {
        "code": "accounts_read",
        "configurations": { "read_transactions": true, "read_holders": true, "from_date": "60 days ago" }
      },
      { "code": "cards_read", "configurations": { "read_transactions": true, "from_date": "60 days ago" } },
      "loans_read"
    ]
  }
}

Leave executions_features out and the session reads your application’s default; with neither, it is refused.

Which banks a session offers

• A bank is offered when it reads at least one of the features you ask for. So one bank may return less than another: retrieved_features, in the results, says what some connection actually delivered.
• customer_information_read never decides on its own. Every bank returns it, so it never makes a bank worth offering — unless it is all you ask for.
• A named engine must read one of them. With engine_reference, an engine that reads none of the features you ask for is refused: 422, engine_serves_no_requested_feature, on settings.engine_reference.

Transactions: accounts and cards

accounts_read and cards_read read the products alone unless you ask for more. Their configurations say what else, and over which window of time:

The limits. A window reaches back at most two years for accounts and one year for cards, and never past today.

Next