Risk Insights can help evaluate the creditworthiness of both new and existing customers. Risk product identifies high-risk behaviours and risk-related data points that results in data points to perform deeper credit assessment or automated customer screening.
Fields from Risk Insights can be used as simple business rules to validate certain criteria is met by customers, and have also proven to be predictive when used as independent features in scoring models.
The risk insights response is sectioned in 8 objects where each object holds descriptive statistics for risk-related categories. High-level overview of each object is described in the table below.
| Key | Count of elements in the object | Nordigen Category ID | Comment |
|---|---|---|---|
alimony_payments | 2 | 137 | |
bailiffs | 2 | 136 | |
balance | 5 | - | |
cash | 10 | 19, 83 | |
debt_collection | 2 | 138 | |
dishonours | 2 | 1402 | Category Dishonours is quite rare, and mostly seen in Australia. It depicts the charge of a person trying to make a payment when not having enough funds to cover the amount |
gambling | 8 | 4402, 4404, 4406 | |
loan_fines | 2 | 562 |
For almost all objects two values are calculated - average_count_a_month and average_sum_a_month - that translates into monthly average amount spent on respective risk-related category. By analyzing both fields together, it allows an analyst to conclude what amount of money is spent towards this category and how often money is spent.
Balance section gives an overview of an individual's cash flow. In most cases a bank account’s start and/or end balance is available in the bank account metadata.
Fields statement_start_balance and statement_end_balance are mapped from bank account metadata. If there is more than one account (the same or different currencies), balances are first unified in the same currency and then summed. If one or both values are not available through metadata the response will be null accordingly.
Net cash flow - net_cash_flow - is the difference between incoming and outgoing transaction amounts. Similarly to other fields (and for consistency), calculations are done for the calendar month subset.
As all calculations are done on calendar months, the start and end balance of first and last month of calendar month subset - calendar_month_start_balance and calendar_month_end_balance - are also returned in the response. To calculate the values, net cash flow of first incomplete calendar month is calculated and added to statement's start balance, and net cash flow of the last incomplete calendar month is calculated and substracted from statement's end balance.
To give an example, let’s imagine that the uploaded statement’s start date is 15th of January and end date is 20th of September, the start of the first full calendar month 1st of February and the end of the last full calendar month is 31st. Statement’s start balance on 15th of January is 1000 EUR and net cash flow from 15th of January till 30th of January is -500, then calendar_month_start_balance is 500EUR. And that means (calendar_month_end_balance - calendar_month_start_balance) = net_cash_flow.
...
"balance":{
"calendar_month_end_balance":900.00,
"calendar_month_start_balance":500.00,
"net_cash_flow":400.00,
"statement_end_balance":900.00,
"statement_start_balance":1000.00
}
...
Edge case handling when one or both balances are not available in the metadata due to the data source:
statement_start_balance is null and statement_end_balance is some value. Both values will be returned in the response accordingly, however in order to calculate calendar month balances, statement’s net cash flow is calculated to get calculated statement’s start balance.
Similarly, if statement_end_balance is null and statement_start_balance is some value - statement’s net cash flow is calculated to get calculated statement’s end balance out of which ultimately calendar month subset’s start and end balances can be calculated.
In the case where both values are null, the calculated start balance of the statement is 0, and the end balance is the statement's net cash flow.
Gambling section gives an overview of an individual's payments to gambling institutions. Income from gambling is not included in the product as easy conclusions can be made - if there are any payments to gambling institutions, there might be some income as well, however if no payments are made, no income will be received from gambling (unless it’s a salary and similar income source).
Two fields - average_count_a_month and average_sum_a_month - have been described before, thus will not be described here.
Field days_since_last_transaction gives an insight into how recent (in days) is the last payment to a gambling institution made.
Note: as outlined in API documentation, the field takes into account last incomplete month’s transactions as well. For example, if we use the same dates from example above - an uploaded statement’s start date is 15th of January and end date is 20th of September, and the last payment to gambling institution is made on 29th of August, then the response value will be 22 days.
The field monthly_regularity_of_gambling is defined as the percentage of calendar months with outgoing gambling transactions. Response value is a float and is in interval [0,1], where 1 represents perfect regularity - gambling expenses made every month.
Fractions ratio_of_casino, ratio_of_lottery and ratio_of_sports_betting gives an insight of the distribution of payments to casinos lotteries and sports betting institutions. Sum of these values will always come up to 1.
And the fraction of all gambling (any gambling type, transaction amounts summed together) to all expenses is calculated and displayed with gambling_to_all_expenses.
Cash section gives an overview of an individual's activities with cash considering both - cash deposits (income) and cash withdrawals (expense).
Monthly average amount and count values have been described before, thus will not be described here. Fields contain keyword cash deposit - average_count_of_cash_deposit_a_month and average_sum_of_cash_deposit_a_month - when calculated for cash deposits made in calendar month subset, and fields contain keyword cash withdrawal - average_count_of_cash_withdrawal_a_month and average_sum_of_cash_withdrawal_a_month - when calculated for cash withdrawals made in calendar month subset.
Fields cash_deposit_monthly_trend, cash_withdrawal_monthly_trend and stable_monthly_cash_deposits can be analyzed together. Same as before, the monthly trend is defined as a slope of linear approximation of monthly cash deposits (or cash withdrawals), whereas cash deposits are stable if time-series of cash deposit values do not fluctuate too heavily. Here, the value is a boolean indicator which is based on stability function and ranges that is also used throughout the income insights, thus value is true if stability >= 0.85.
Last three fields - cash_deposit_to_income, cash_withdrawal_to_expenses, cash_withdrawal_to_income - gives an insight into what fraction of income (or expenses) is coming from cash deposits (or cash withdrawals) based on sum of transaction amounts.