Product Customization

Introduction

All insights products can be customized by the end-user, allowing the insights products to suit different regulatory requirements and/or internal procedures. The parameters for customization are listed in the table below:

Accounts

(Corresponds to drop_shared_accounts and drop_joint_accounts)

An individual can have multiple bank accounts, however in cases where a bank account is not used by an individual directly (hence does not capture an individual's financial behaviors) it might make sense to not process said account. Some examples of this are spouses having a joint account, or parents being the owners of their child's account.

Based on bank account meta-data it is possible to distinguish personal accounts, joint accounts and shared accounts, and exclude irrelevant bank accounts from further analysis. Mentioned account types are described below:

• Personal account - a bank account for use by an individual for that person's own needs. That could be all types of bank accounts, for instance, checking accounts, saving accounts or others. Account holder is the person who gives consent to process the bank statement data.

• Joint account - a bank account between two or more individuals. Joint account holders have equal access to funds but also share equal responsibility for any fees or charges incurred. 

• Shared account - a bank account where the account holder is another person than the individual who gives consent to process the bank statement data. For example, the account holder is a child of the respective individual.

Default behaviour is to analyze all accounts that are sent through the request. However, parameters drop_shared_accounts and drop_joint_accounts gives end-user the control to exclude certain types of accounts. 

For sanity check purposes:

• If categorisation is requested, each account object in the categorisation response returns boolean values for fields is_joint_ownership and is_shared_ownership indicating what type of account is it.

• Possible respective field combinations are - false-false (personal account), true-false (joint account) and false-true (shared account), but never true-true as an account cannot be joint and shared account concurrently.

• Uploaded statement and respective parameter values are summarized in the response metadata section. Below is an example of values for statement-details object if a statement contains 5 accounts out of which 3 are irrelevant for analysis.

      {
          "data": {
              "attributes": {
                  ...,
                  "metadata": {
                      "statement-details": {
                          "count_of_analysed_accounts": 2,
                          "count_of_uploaded_accounts": 5,
                          "drop_joint_accounts": true,
                          "drop_shared_accounts": true
                      }
                  },
                  "status": "completed"
              },
              "type": "report processing status"
          }
      }

Transaction currency unification

(Corresponds to currency)

A statement can contain multiple bank accounts where each account has a different currency, therefore it’s important to unify all transaction amounts into one currency before performing any analysis.

One of the most obvious reasons why data analysis cannot be performed over a multi-currency statement is that output field values lose any meaning. For example, if a salary is received in one account in Swedish krona and income from rent is received in another account in euro then without unifying amounts in one currency all calculations are flawed and no conclusions can be made.

If currency is not passed, the main currency of a statement's country is used. For Australian statements it would be Australian dollars, for Swedish statements - Swedish kronas, and for most European countries it is euro.

Currency exchange rates are updated on a daily basis, and aligns with the exchange rates published by the European Central Bank. 

For sanity check purposes, if Income, Risk or Loans products are requested, the response always contains insights-details object, where all currency conversions (including applied conversion rates) are listed together with the display currency. For example, if all field values like average salary are displayed in euro and no currency conversions are done, the below response will be returned.

   
      ...
      "metadata":{
         "insights-details":{
            "currency":{
               "applied_currency_conversions":[
                
               ],
               "display_currency":"EUR"
            }
         }
      }
      ...

Whereas, for instance, if display currency is set to Polish zloty (PLN) and the uploaded statement has one account with transactions in Polish zloty (PLN), one account with transactions in Australian dollars (AUD) and another account in euro (EUR), response will enclose all currencies and respective conversion rates from AUD and EUR to PLN.

  
      ...
      "metadata":{
         "insights-details":{
            "currency":{
               "applied_currency_conversions":[
                  {
                     "currency":"AUD",
                     "rate":2.94
                  },
                  {
                     "currency":"EUR",
                     "rate":4.55
                  }
               ],
               "display_currency":"PLN"
            }
         }
      }
      ...

Transaction subset

(Corresponds to period)

Most calculations in insights products are performed on full calendar month data only, thus only a subset of available transactions are used. Meaning, if a statement’s first and/or last  calendar months are incomplete, respective transactions are dropped and not taken into account for calculations, even if an incomplete month holds information about income like salary.  

The described behaviour ensures that fields are not dependent on the application date or data extraction date, thereby does not add any penalty points for the applicant during the decision process - manual or automatic. For example, if a private individual usually receives salary on 10th of each month, but statement’s export is made on 4th, it would seem that there is no income in the last month and skew the calculations. 

Due to the nature of some fields, sometimes incomplete calendar months are also used, and for all fields it has been outlined in the API documentation. For example, Income product’s days_since_last_income_payment field takes into account end date of statement, otherwise field’s value would always include count of last incomplete month’s days which is not relevant information for respective field.

Data subsetting behaviour when period is not passed (default):

Example #1: all statement’s months are full calendar months. Statement’s start date is 1st of January, end date is 31st of December. Transaction subset holds all transactions from the uploaded statement.

Example #2: first and/or last month are not full calendar months. Statement’s start date is 15th of January, end date is 15th of December. Transaction subset holds all transactions from 1st of February till 30th of November as the start month (January) and the end month (December) are not full calendar months.

Data subsetting behaviour when period is passed. For example purposes, let’s imagine that period is set to 3 (calendar months):

Example #1: all statement’s months are full calendar months. Statement’s start date is 1st of January, end date is 31st of December. Period is set to 3, hence the transaction subset will hold all transactions from 1st of October to 31st of December.

Example #2: first and/or last month are not full calendar months. Statement’s start date is 15th of January, end date is 15th of December. Period is set to 3, hence the transaction subset holds all transactions from 1st of September till 30th of November as the start month (January) and the end month (December) are not full calendar months.

Income and expense definition

Income insights can be tailored with custom income and expense definitions to seamlessly blend with existing decision engines and internal procedures.

Both definitions are made based on Nordigen categories and taxonomy.

Income definition impacts whole insights response and is referenced as “income” throughout the product. For example, average_monthly_income is calculated over all transactions that are recognized with listed income categories in the set definition. The same logic is applied in other response fields like debt_to_income_ratio, days_since_last_income_payment and others. Each category from the definition is also listed and separately described in the income_by_category object.

Default definitions are listed in the API documentation.

For some traceability, income product response returns definitions object that holds information about applied income and expense definitions. For example:

• only salary and pension are recognized as legitimate income,

• and mortgage and monthly utility payments are recognized as the only essential and mandatory expenditure to be considered,

and respective Nordigen categories are set as income and expense definitions respectively, then the definitions object would hold information as shown below:

   
      ...
      "definitions":{
         "expenses":[
            {
               "category_id":"29",
               "title":"Utility services"
            },
            {
               "category_id":"97",
               "title":"Mortgage"
            }
         ],
         "income":[
            {
               "category_id":"85",
               "title":"Salary"
            },
            {
               "category_id":"5",
               "title":"Pension"
            }
         ]
      }
      ...