General concepts

When compared to clasic bank statements (printed or exported as PDF/Excel through classic channels), transactions and balances received via APIs have two main differences:

• They may arrive as fast as they are created at the bank, giving you almost real time insights into your cashflow
• They may capture intermediate states, which are not considered as final / completed by the bank and may still change over time

As a consequence, FinqTreasury implements and exposes a generic synchronisation mechanism which allows us to systematically handle this iterative and dynamic change process accross all banks.

We use a versioning mechanism based on:

• Uniqueness: each transaction is uniquely identified based on attributes (which may differe from bank to bank)
• Incremental RowVersion: each record inserted receives a RowVersion which represents the moment in time when it was inserted. An update of the same record increases its RowVersion to the current moment in time.

RowVersions allow us to:

• order all inserts and updates in the physical order they happened (we give you transactions in the same physical order we fetched them from the bank)
• allows reliable pagination of data fetches (when you skip through pages using the max row version from the previous page as the start row version for the current one, we guarantee you won't get the same version of the same record twice)
• give you a reliable way to decide if you need to insert or update a transaction (if you can find a transaction by Id in your database, comparing their RowVersion attribute will tell you that the one with the larger RowVersion is the newer version)
• guarantee that, at the moment of the request, there is no other newer version in our database for each transaction (you always get the latest version we have)