Data Intelligence Platform

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:

• 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.

To provide data in the highest possible quality, Data Intelligence Open Finance services analyze the external data received from finAPI Access (https://docs.finapi.io/ ) via finAPI Web Form 2.0 (WebForm 2.0 Documentation), such as account data, transactions, band and data, by using a combination of an expert knowledge system, driven by clearly defined rules, and machine learning approach for providing a label coverage for approximately 80% of all transactions and aggregation the information into the decision-ready state.

Furthermore, we use cutting-edge technology for constantly enhancing our services, from data analysis pipelines to an event-driven system, which is built in scalable modules, that you also may use in a proprietary environment or as a SaaS. If you are interested in this kind of usage or want to know more, please feel free to contact us for an offer. We are looking forward to hearing from you!

Follow-up

The following sections describe the technical steps needed for integration. It is an additional resource that completes our Swagger description of the REST API. If you experience any problems with our integration or just have some questions, please contact our support at any time at support@finapi.io. Our customer success team is happy to help you to bring your services consuming finAPI REST APIs to success.

1. Data Source Import

The following types of data sources can be created in DI:

• Bank Connection data sources (imported via Web Form 2.0)

• Schufa Credit Check data sources (provided by Schufa WS)

• Transaction data sources (where accounts and transactions for analysis are provided via API endpoint)

Bank Connection Data Source

Initial Import

Open

Bank Connection Data Source

To create a data source (bank connection) in DI:

1. Authorize/create a user (-identity), as described in https://finapi.jira.com/wiki/spaces/DIPD/pages/2344550464. The sequence diagram above shows authorization as a user (uses: Access, <ACCESS_URL>). Alternatively, it is possible to create a process and obtain an OAuth token for the process (uses: Process Ctl, <PCL_URL>).

2. Import the Bank Connection with the help of finAPI Web Form 2.0 (POST <WF_URL>/api/ webForms/bankConnectionImport).

3. Upon successful completion of the SCA (web form), make a call to the DI POST <DI_URL>/api/v1/ dataSources / bankConnections / synchronization with included callbackUrl (optional) and retrieve the imported bank connection with the DI dataSourceId.

3a. In case the callbackUrl has been provided, DI will send a notification to the client once the Data Source synchronization is finalized (with SUCCESSFUL or ERROR)

3b. In case the callbackUrl has not been provided, poll GET <DI_URL>/api/v1/dataSources/ {dataSourceId} / status until the data source status is SUCCESSFUL or ERROR.

NOTE: The bank connection is not considered imported until the SCA (webform) is completed successfully.

NOTE: The bank connection that was imported through Web Form 2.0 will be reflected in DI only once the POST <DI_URL>/api/v1/ dataSources / bankConnections/synchronization call is made. Before the call is made, the DI database has no data sources (bank connections) stored for a particular user.

NOTE: Recommended polling frequency of the Data source status is 1 sec. Maximum recommended polling time - 5 min.

Update Initiation

The major prerequisites for updating a data source (bank connection) in DI are:

1. Data source synchronization call returned bank connection in status FAILED

2. Calling GET <DI_URL>/api/v1/dataSources/{dataSourceId}/status resulted in the status FAILED and code UPDATE_REQUIRED.

To update a data source (bank connection) in DI:

1. Update the imported earlier Bank Connection with the help of finAPI Web Form 2.0 (POST <WF_URL>/api/ tasks/backgroundUpdate ).

2. Upon successful completion of the SCA (web form), and in case the callbackUrl has been provided, poll the DI POST <DI_URL>/api/v1/dataSources / {dataSourceId} / status until the data source status is SUCCESSFUL.

NOTE: Recommended polling frequency of the Data source status is 1 sec. Maximum recommended polling time - 5 min.

NOTE: Synchronization endpoint should not be used for data source update.

Schufa Credit Check Data Source

The major prerequisites for creating a Schufa Credit Check data source are being authorized in DI and having a set test account on the Schufa side.

To create a Schufa Credit Check data source through DI, make a call to DI POST <DI_URL>/api/v1/dataSources/schufaCreditCheck and pass the following request body, where only the schufaId, title, placeOfBirth and country are optional for completion.

The Schufa Credit Check data resource creation response body looks as follows (in case performed successfully):

NOTE: In comparison to Bank Connection Data Source, the process of creation of the Schufa Credit Check Data source is synchronous. Thus in case the dataSourceId is obtained, the data source is considered to be successfully imported and requires no further actions from the client’s side.

Transaction Data Source

A transaction data source allows the usage of Data Intelligence, if you have your own source to provide account and transaction data, and you want to label and analyse it.

To create a Schufa Credit Check data source through DI, make a call to DI POST <DI_URL>/api/v1/dataSources/transactions.

In case the callbackUrl has been provided, DI will send a notification to the client once the Data Source synchronization is finalized (with SUCCESSFUL or ERROR)

In case the callbackUrl has not been provided, poll GET <DI_URL>/api/v1/dataSources/ {dataSourceId} / status until the data source status is SUCCESSFUL or ERROR.

For all further details on the request and response body objects refer to the API description: https://docs.finapi.io/?product=di.

2. Case Creation

The major prerequisite for creating a case is getting the IDs of the data sources (dataSourceId) from Step 1, based on which the reports in the given case will be created.

To create a case, make a call to POST <DI_URL>/api/v1/cases and pass the following parameters:

• dataSourceids= the IDs of all the data sources (dataSourceId) or particular accounts inside these data sources (in case of Bank Connections) (accountId) based on which the reports in the being created case will be provided.

• maxDaysForCase = number of days, the data from which will be analyzed for report creation (applicable for Bank Connection Data Sources only).

  Example: A case file is created on Oct 10, 2020 and has a Bank Connection Data Source inside; maxDaysForCase=9 => all the reports that will be created in this case file, will have the analyzed data for period Oct 1, 2020 to Oct 10, 2020.

The case creation response body looks as follows (in case performed successfully):

NOTE: The case file creation won’t be successful until the data sources connected with it have the data import finished (in the case of Bank Connection Data Sources).

NOTE: The maxDaysForCase parameter limits the range of data provided in Bank Connection Data Sources, but does not influence in any way the data inside the Schufa Credit Check Data Source.

3. Reports Creation & Getting

Risk, Cash Flow, B2B, Contracts Reports - all reports are listed in a drop down in Rapidox

The major prerequisite for creating and getting the report is having the caseId of the successfully created case file from Step 2.

To create a report of a particular type (Chargebacks, Gambling, B2B Balances, Insurance) and of a particular category (Risk, Cash Flow, B2B, Contracts ), make a call to POST <DI_URL>/api/v1/cases/{caseId}/report. The type of the report is specified in the body of the call.

The response contains the reportId of the created report:

To get a report of a particular type (Chargebacks, Gambling, B2B Balances, Insurance) and of a particular category (Risk, Cash Flow, B2B, Contracts), make a call to GET <DI_URL>/api/v1/reports/{reportId}.

Continuous Reports

It is possible to create a report, that continues an existing/previous report, by making a call to POST <DI_URL>/api/v1/cases/{caseId}/report, which includes the object continuousReport.

NOTE: Every case file may have a maximum of one report of a particular type: e.g. 1 case file may have 1 Chargebacks report, 1 Gambling report, and 1 Insurance Report (child reports are not taken into account for this count).

Transactions Labeling in Reports

Calling the endpoint GET <DI_URL>/api/v1/labels?reportType=<REPORT_TYPE> returns the currently defined labels, with their descriptions.

Specifying the report type you can get the relevant labels for a specific report.

For all further details on the request and response body objects refer to the API description: .

Digital Account Check (DAC) Reports

DAC services allow the creation of a case file with multiple Risk and/or Cash Flow reports within a single API call: POST<DI_URL>/api/v1/dacCases/loan

The major prerequisite for creating and getting the DAC reports is getting the IDs of the data sources (dataSourceId) from Step 1, on the basis of which the reports in the given case will be created. For the creation of a case with a DAC report, the same rules as for Case Creation apply (see step 2).

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.

Report use cases

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:

1. Select one of the pre-defined triggers via POST <DI_URL>/api/v1/reports/{reportId}/triggers/cashFlow

2. 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.

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.

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, the DELETE <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.

The user deletion request response will contain the deletionId:

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).

NOTE: The data for the user will be deleted in DI only. The data imported for the user in Access will remain unless it is deleted directly on the Access side. You may re-synchronize the backends if you want to create new data sources, cases and reports.