# The back-end ### A simple UML design for the database ![](/files/maZxJqVYnZq16xPTsTvs) ### 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, Transactions`tables: 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](https://github.com/finqware/gitbook-public-docs/blob/main/dev-guide/designing-a-tenant-app/broken-reference/README.md). 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.finqware.com/dev-guide/designing-a-tenant-app/the-back-end.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.