Introduction to Savings
Identify your client's saving habits and thereby guide patterns and opportunities.
What it solves
The existing savings behavior says a lot about a person. On the one hand, the products used (call money, fixed-term deposits, home savings, shares, etc.) show how risk-averse a person is. On the other hand, it shows which opportunities are not yet being used. In addition, savings behavior can show whether and how much a person is used to putting something aside.
Savings Report
The Savings Report is based on the label SAVINGS
, and its further sub-labels with a higher level of detail.
The report gives an overview of data such as the number of relevant transactions. How much money does the customer save? What kind of savings does the customer use?
Other data includes the account information and the transactions used in the report. This is very helpful if you want to check the values, for example, as part of a detailed credit check.
In addition, further reports can be created based on an initial report. These continuous reports can then be provided with triggers that always compare the values of the previous report with the current one and look for defined changes.
This is useful if you have access to the client's account data over a longer period of time.
It is important that not only days, but ideally months are considered.
Aggregations
A Savings Report can be generated as an Aggregation with the following query:
{
"aggregations": [
{
"alias": "Savings",
"includeLabelGroup": [
"SAVINGS"
]
}
]
}
Used data fields
All transactions of the customer are used for this purpose. This includes data like IBAN
, account holder name
, counterpart name
, purpose
, amount,
and so on.
The report response itself is divided into the following sections.
Main Section
The main part of the report can be found at $.reports.savings
and the type
will be SAVINGS
.
This gives you a quick overview of the transactions used in the report through aggregated values that can serve as a summary.
A full API schema can be seen here: https://docs.finapi.io/?product=di#get-/cases/-caseId-/reports
Field | Description | Mandatory |
---|---|---|
| Timestamp of when the report was created, in the format ' | yes |
| ID of the case in which the report was created. | yes |
| Defines the type of the report. | yes |
| Timestamp of the start date of the reporting period under review in the format ' | no |
| Timestamp of the end date of the reporting period under review in the format ' | no |
| The number of full days, that the reporting period under review contains. | no |
| Timestamp of the date, when user's first transaction took place in the report period under review in the format ' | no |
| The number of the user transactions, that took place in the report period under review. This field takes into consideration all the transactions of the user, irrespectively of the assigned to them label. | no |
| The total count of positive transactions in the report. | yes |
| The total count of negative transactions in the report. | yes |
| The total income. | yes |
| The total spending. | yes |
| The total balance. | yes |
| List of accounts-related data with the relevant transactions information. | no |
| List of reports, created automatically with the specified frequency (defined by | no |
Account Data Section
The account data section can be found under the accountData
field.
It contains data about the account at the first level.
If more than one account is included in the report, they will be displayed individually in the list.
Field | Description | Mandatory |
---|---|---|
| Name of the bank. | yes |
| Unique identifier of the Bank, generated by finAPI. | yes |
| IBAN of the bank account. | no |
| Unique identifier of the bank account belonging to the imported bank connection. | no |
| List of transactions related to the chosen report type. | no |
Transactions Section
This section displays the transactions used in the report and can be found under the accountData
element in the field transactions
.
Please note that this list may be very long, especially for business accounts.
Depending on what the report is used for, the transactions can be retrieved for later review or documentation, or they can be turned off. The latter would be the case, for example, if you only want to do a quick check of the overall data and do not need any details.
If transactions are not of interest, you can also disable this section by giving the query parameter withTransactions=false
to the report.
The transactions include the following values.
Field | Description | Mandatory |
---|---|---|
| Value date in the format ' | yes |
| Bank booking date in the format ' | yes |
| Transaction amount. | yes |
| Transaction purpose. | no |
| Counterpart name. | no |
| Counterpart account number. | no |
| Counterpart IBAN. | no |
| Counterpart BLZ. | no |
| Counterpart BIC. | no |
| Counterpart bank name. | no |
| A list of labels assigned by the system. This does not contain the complete label structure in the sense of level of detail. | no |
| Includes a much more detailed view of the labels including all level of detail and the most significant labels. To see this section, the report must be called with the query parameter | no |
| Extracted details for transactions with related to overdraft interests. | no |
Label Details Section
To get more information about labels or the whole Level of Detail structure, this section can be enabled using the query parameter withLabelDetails=true
.
This is particularly interesting if you want to perform your own evaluations based on the reports. You are able to select all transactions of a certain level of detail because the complete structure is available.
Field | Description | Mandatory |
---|---|---|
| List of labels including their Level of Details structure. | yes |
| List of labels including the level of details as a flat list. | yes |
| Most significant labels in the report context including its level of detail, depending on the priority of labels. | yes |
| Most significate label of level 1 | no |
| Most significant income related label of level 2 | no |
Labels with Level of Details
The general part of the Label Details section is summarized in the labelsWithLevelOfDetails
field.
This shows the complete structure for each label in a list.
For example, if a label with REALESTATELOAN
was output in a transaction, this element returns the following structure for the label:
LoD 1:
BANKANDCREDIT
LoD 2:
LOANANDINTEREST
LoD 3:
REALESTATELOAN
This allows to derive some more context and it allows to select for example LOANANDINTEREST
in all issued transactions of the report, should one be interested only in such transactions.
Since labels may belong to several label groups (e.g. CARLOAN
is both LOANANDINTEREST
and MOBILITY
), it is possible to identify which groups are involved.
Labels Expanded Lower Level of Details
In the field labelsExpandedLowerLod
a simple list of all labels and their level of details is displayed. However, there is no order of the levels, but only all labels, including the levels below them, are displayed as text.
Therefore, this field is best suited for a simple one of a particular label group.
Most significant labels
The mostSignificantLabels
field returns the most appropriate labels in the report context including its level of detail.
This is controlled by the priorities when the report is created.
For example, if a transaction has the label CARLOAN
, it may appear in the level of detail 1 in the groups MOBILITY
and BANKANDCREDIT
.
However, by using the priorities, which map what you are most interested in, only one group is returned here.
For example, if the priority of BANKANDCREDIT
is higher than that of MOBILITY
, the structure of BANKANDCREDIT
will be returned.
The reverse would be the MOBILITY
group.
Most significant Level of Detail 1
This area is represented by the field mostSignificantLod1
.
Only the most important label of level 1, is returned. This is the label that has the highest value in the level.
This is provided for the selection of transactions at level 1. The assumption is that a higher level of detail often results in more accurate, specialized recognition.
Most significant Level of Detail 2 for income transactions
If there are multiple labels in an incoming (positive) transaction, the most significant label is mapped here.
This is also based on the priorities, which can be set with the field incomeLevelOfDetail2Priority
when creating the report.
As a result, the highest level of detail of the transaction is returned here, which can be an indicator that this is the most accurate context.