...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
| Table of Contents | ||||
|---|---|---|---|---|
|
Welcome to Data Intelligence!
...
...
...
...
...
Welcome to Data Intelligence!
With finAPI Data Intelligence REST services we want to provide a deeper insight into the picture that describes a consumer’s financial situation based on our Open Banking solution.
We already provide intelligent banking API services suitable for an end user's individualized personal finance management experience with our Access PFM product. However, with Data Intelligence we can provide our customers with an even clearer picture of the financial situation of their consumers and users.
To achieve this we structured our Data Intelligence services accordingly:
...
With finAPI Data Intelligence REST services we want to provide a deeper insight into the picture that describes a consumer’s financial situation based on our Open Banking solution.
We already provide intelligent banking API services suitable for an end user's individualized personal finance management experience with our Access PFM product. However, with Data Intelligence we can provide our customers with an even clearer picture of the financial situation of their consumers and users.
To achieve this we structured our Data Intelligence services accordingly:
The Risk Reports section provides reports related to the user's banking transactions which might indicate a payment risk if e.g. our customer provides goods with a payment plan to this consumer. We detect these risky transactions and bundle them under one report, which an application on our customer's side can consume within seconds.
To gain a deeper understanding of the cash flows of your end users, we offer the Cash Flow Reports section. Here is a variety of income and expenditure-related reports, in which we aggregate and summarize the according transactions belonging to a specific field, like insurance, income or rent, and living, etc.
...
The case file id returned in the response of the call should be used as an input path parameter for GET<DI_URL>/api/v1/cases/{caseId}/reports to retrieve the DAC report results.
...
DI Report | Use Cases |
|---|---|
Contract Detection | Accounting Comparison Portals LoanValidator |
DAC and Risk Reports | Loan decision making Loan and credit card limit determination KreditCheck |
...
LoanValidator | |
DAC and Risk Reports | Loan decision making Loan and credit card limit determination KreditCheck |
4. Using Triggers
DI allows its clients to set triggers for a continuous report (see above). Triggers are special conditions, set by the client. Once any of the created child reports meet the defined condition, the user gets notified, that the trigger even took place.
There are two ways to set triggers:
Select one of the pre-defined triggers via POST <DI_URL>/api/v1/reports/{reportId}/triggers/cashFlow
Create your own trigger via POST <DI_URL>/api/v1/reports/{reportId}/triggers
Pre-defined triggers
For example, if the client wants to get notified when the user’s salary amount will change, he can use SALARYAMOUNTCHANGE pre-defined trigger. For this make a call to POST <DI_URL>/api/v1/reports/{reportId}/triggers/cashFlow with the triggerType = SALARYAMOUNTCHANGE and reportId of the initial (parent) report.
Creating your own trigger
In case none of the pre-defined triggers can cover the client's needs, the client can create his own customized trigger.
Example 1
For example, if the client wants to get notified once the user concluded a new health insurance contract, the following trigger for continuous Contracts Report for Insurances can be set via POST <DI_URL>/api/v1/reports/{reportId}/triggers. To do this the client should find the contracts of contractType= HEALTHINSURANCE AND newContract=true, to ensure that the contract is new for the user.
| Code Block |
|---|
...
"triggers": [
{
"path": "$.contractsData[*].contractType",
"operator": "EQ",
"value": "HEALTHINSURANCE",
”and": [
{
"path": "$.contractsData[*].newContract",
"operator": "EQ",
"value": true
}
]
} |
Example 2
Another example of own triggers creation can be as follows: the client needs to be notified once a user has new gambling or debt collection-related transactions, to define risk level for the user’s account. To do this, the client should find the transactions with GAMBLING OR DEBTCOLLECTION labels.
| Code Block |
|---|
...
"triggers": [
{
"path": "$.accountData[*].transactions[*].labels,
"operator": "EQ",
"value": "GAMBLING"
},
{
"path": "$.accountData[*].transactions[*].labels",
"operator": "EQ",
"value": "DEBTCOLLECTION"
}
]
}
|
Trigger Results
The results of the trigger evaluation will be included in a continuous report, which means a report that has been created with a provided continuousReport object during its creation.
5. User’s DI Data Deletion
In case it is needed to remove the DI data of the user, such as the created Data Sources, Reports, and Cases, theDELETE <DI_URL>/api/v1/ user endpoint can be used.
To delete the user’s data it is mandatory to pass a valid user access_token.
...
To ensure whether the deletion process has been finalized for the user, the obtained deletionId should be used for GET <DI_URL>/api/v1/user/status/delete/{deletionId} call. The response of the call is aimed at providing detailed data on the status of data deletion at each DI module (application).
...