The back-end

Building a data model.

A simple UML design for the database

Data model

Central to this design is the users table. This is where you store end-user identities for authentication.

Skills table: an inventory of skills (Bank connectors) that were registered by our tenant app. There is a many-to-many relation with users - a user may choose to connect to many Banks; a skill me be used by many users. This table is maintained manually because it contains mostly static information. Whenever we configure a new skill to the tenant app, we add a new record here, making sure you have a Servicer record first (see below). Once the record is added, it should show up in the user's GUI as a new option to connect.

Accounts, Balances, Transactionstables: a cache of data coming from Finqware. Note: Finqware strives to be highly available but having your own cache for a better service level is never a bad idea.

Servicers table: each Bank has its own record here. There is a one-to-many relationship with skills: there could be more than one skill from a certain bank (eg: account info, payment initiation - both from the same Bank). This table is maintained manually because it's mostly static information. You would add a new Servicer when the skill you want to implement is from a new Bank you don't have already.

Sessions, steps tables: keeps a local state for implementing the Sessions API. By keeping this state you make sure the client app is 'guided' to show the right screen and you avoid wrongly submitted forms.

Storing consent data

Following a successful consent flow (finishing with the temp_token exchange) your tenant app receives a credentials_id and its access_token. This pair is used by your app in order to query for data such as: one or more bank accounts, a payment object.

One place to store this information is user_skills table which, in this example is a proxy (typical many-to-many proxy table) that makes the connection between the user and the skills/features they chose to connect with.

One thing to note: a consent object (the credentials_id/access_token pair) may point to more than one resource (eg: bank account). This maps to the PSD2 consent objects which expresses the same relationship. That is why it makes sense to store it in a record that expresses the direct relation between the end-user and skills that they used via the client UX.

Caching data

Finqware manages its own caching of the data. By default it refreshes the data for you based on a pre-defined schedule. Currently this is four times per day, but it will be possible to be configured via the developer portal.

Our backend is highly available and we serve data with a super-low latency, striving for realtime. However, building and keeping your own cache is something recommended in order to offer a more predictable SLA to your customers.

Business logic

This is where your own data processing happens: build statistics, apply ML models, transform data in any way etc. May be developed in your language of choice.

Your app will probably have a private API (eg: REST or GraphQL) that is consumed by the front-end (unless your data is rendered server-side).

Custom extensions

We are currently working with selected customers to build custom extensions on top of the base API: income recognition, statistics etc. If your company is interested in such developments, please contact us.