There are certain standards and requirements you need to adhere to when you offer open banking services as a PSD2 compliant organization. The Account Servicing Payment Service Providers (ASPSPs) are required to make their statistics available to respective national authorities and open banking authorities to monitor compliance with PSD2/RTS. In order to satisfy this, the WSO2 Open Banking solution offers data reporting feature.
The Data Reporting feature gathers and monitors data in regard to the APIs invoked through the WSO2 Open Banking solution. This observes the following aspects.
- Performance and availabilityÂ
  Understand and monitor the availability and performance of the supported APIs. - AdoptionÂ
  Identify the effectiveness; which ASPSPs are being engaged more by TPPs as part of their ongoing activity. - Data volumetricsÂ
  The efficacy of the Open Banking standards as a part of ongoing standards management activity.
The WSO2 Open Banking Business Intelligence(OBBI) captures the data through WSO2 Open Banking API Manager(WSO2 OB APIM) and WSO2 Open Banking Key Manager(WSO2 OB KM). It processes and summarizes the data in a way that ASPSPs can generate their own reports and summaries.
Data Reporting captures the data in the following flows Â
API invocation data from the AISP and PISP flows
Authentication data through Strong Customer Authentication flow
Authorization data using the Authorization flow
Application registration data through the TPP onboarding process
All the data are stored in two databases.
The OB_REPORTING_DB
database stores all the raw data related to API invocation, authentication, authorization and application registration. The data stored in the database is not processed by any means, therefore the ASPSPs can use this database and summarize data according to their requirements.
Click here to see what is included in the OB_REPORTING_DB
The OB_REPORTING_DB
database contains the following tables.
The OB_REPORTING_SUMMARIZED_DB
database stores summarized data of OB_REPORTING_DB
database. The summarization contains information related to API invocation, consents, single and batch payment information, payment submission, etc.
Click here to see what is included in the OB_REPORTING_SUMMARIZED_DB database
The OB_REPORTING_SUMMARIZED_DB
database contains the following summarized data tables:
BACS_REQUEST_STATUS
Stores summarized status details of the BACS payment requests.
FAILED_BACS_REQUESTS
Stores summarized details of failed BACS requests.
CHAPS_INTERNATIONAL
Stores summarized details of CHAPS international payments.
CHAPS_REQUEST_STATUS
Stores summarized status details of the CHAPS payment requests.
FAILED_CHAPS_REQUESTS
Stores summarized details of failed CHAPS requests.
PA_CORE
Stores summarized details regarding performance and availability for core hours (06:00-00:00).
PA_NON_CORE
Stores summarized details regarding performance and availability for non-core hours (00:00-06:00).
RESPONSE_OUTLIER
Stores summarized response details of requests.
PAYMENT_INITIATION_DETAILS
Stores summarized payment initiation details per second.
FILE_PAYMENT
Stores summarized details regarding the number of payments per payment type in (files) file payment requests.
DIFFERENT_TPPS
Stores summarized details regarding the distinct TPP count.
AUTHENTICATION_ATTEMPTED
Stores summarized details regarding the number of attempts to authenticate.
AUTHENTICATION_SUCCESSFUL
Stores summarized details regarding the number of successful PSU authentications.
AUTHORISATION_SUMMARY
Stores summarized counts of authorisation statuses (Authorised/
Rejected
).
- MULTI_AUTH_DETAILS
Stores the summarized count of Authorised/Rejected
statuses in scenarios where multiple authorising is performed. - CONFIRMATION_DETAILS
Stores the summarized count of AuthorisationRequired,Authorised
and Rejected
statuses. - CONSENT_REQ_AUTHENTICATION
Stores the summarized count of PSU consents that require authentication. STATUS_CODE_SUMMARY
Stores the summarized number of API calls for a given endpoint per status code per day.
- PSU_DETAILS
A raw data table that stores PSU details and is used to identify the PSUs.
FIRST_TIME_USERS
A raw data table that stores details of PSUs that use a PIS service for the first time.
ACCOUNT_RAW_DATA_FOR_PCA_BCA
A summarized raw data table that stores the account IDs to identify the Personal Current Account (PCA) or Bank Customer Account (BCA).
FUNDS_RAW_DATA_FOR_PCA_BCA
A summarized raw data table that stores the account IDs to identify the PCA or BCA.
PAYMENT_RAW_DATA_FOR_PCA_BCA
A summarized raw data table that stores the account IDs to identify the PCA or BCA.
Generating reports using summarized data
Using the OB_REPORTING_SUMMARIZED_DB
you can generate the following reports according to the OBIE templates:
- Template 1 - P & A (OBIE)
- Template 2 - Response Outliers (OBIE)
- Template 3 - Auth Efficacy (OBIE)
- Template 4 - PSU Adoption (OBIE)
- Template 5 - Payments Adoption (OBIE)
- Template 6 - TPP Volumes (OBIE)
- Template 7 - Daily Volumes (OBIE)
Click here to see more details
Using the table in the OB_REPORTING_SUMMARIZED_DB
database, the following report templates in OBIE can be generated.
Template 1 - P & A (OBIE)
Required data point name | Table to refer | How to capture data |
---|
Report Date | The respective table you get the date from | Get the year-month-date values from the table |
ASPSP Brand ID | N/A | A fixed value for a bank. |
Endpoint ID | ENDPOINT_DETAILS | A fixed value. Get the resource from the respective table and map that with the ENDPOINT_ID table. |
Core/Non Core Hours | Either Core or Non-Core | This column should be either CORE or NON-CORE . |
Up Time | N/A | Need to get from an external tool. |
Planned Downtime | N/A | Value needs to be decided by the bank. |
Unplanned Downtime | N/A | Need to get from an external tool. |
Median TTLB Response Time | PA_CORE or PA_NON_CORE | Get the AVG_TTLB value from the relevant table per day per time per endpoint. |
Median TTFB Response Time | PA_CORE or PA_NON_CORE | Get the AVG_TTFB value from the relevant table per day per time per endpoint. |
Median Response Payload Size | PA_CORE or PA_NON_CORE | Get the AVG_RESPONSE_PAYLOAD_SIZE value from the relevant table per day per time per endpoint. |
Max Payment Initiations Per Second (PIPS) | PAYMENT_INITIATION_DETAILS | Get the payment initiations per second per day. |
Template 2 - Response Outliers (OBIE)
Required data point name | Table to refer | How to capture data |
---|
Report Date | The respective table you get the date from | Get the year-month-date values from the table. |
Time | The respective table that you get the time from | Get the hour-minute-second values from the table. |
ASPSP Brand ID | N/A | A fixed value for a bank. |
Endpoint ID | ENDPOINT_DETAILS | A fixed value. Get the resource from the respective table and map that with ENDPOINT_ID table. |
TTLB Response Time | RESPONSE_OUTLIER | Get the TTLB value per day per time per endpoint. |
TTFB Response Time | RESPONSE_OUTLIER | Get the TTFB value per day per time per endpoint. |
TPP Application ID | RESPONSE_OUTLIER | Get APP_SOFTWARE_ID value per day per time per endpoint. |
Response Payload Size | RESPONSE_OUTLIER | Get RESPONSE_PAYLOAD_SIZE value per day per time per endpoint. |
Template 3 - Auth Efficacy (OBIE)
Required data point name | Table to refer | How to capture data |
---|
Month | The respective table you get the month from | Get the year-month values from the table. |
ASPSP Brand ID | N/A | A fixed value for a bank. |
Authentication Type | The respective tables | Each table contains a column with this data. |
API Type | The respective tables | Each table contains a column with this data. |
API Request TPP Channel | The respective tables | Each table contains a column with this data. |
ASPSP Authentication Channel | N/A | The value should be web. |
Consents Requiring Authentication | CONSENT_REQ_AUTHENTICATION | Get the TOTAL_CONSENT_REQ_AUTHENTICATION value from the column. |
Authentications Attempted by PSUs | AUTHENTICATION_ATTEMPTED | Get the TOTAL_ATTEMPTS_TO_AUTHENTICATE value from the column. |
Authentications Abandoned by PSUs |
| Get this data by deducting the value of
TOTAL_ATTEMPTS_TO_AUTHENTICATE
from the value of
TOTAL_CONSENT_REQ_AUTHENTICATION. |
Authentications Succeeded | AUTHENTICATION_SUCCESSFUL | Get the SUCCESSFUL_AUTHENTICATIONS
value from the column. |
Authentications Failed |
| Get this data by deducting the value of
SUCCESSFUL_
AUTHENTICATIONS
from the value of
TOTAL_ATTEMPTS_TO_AUTHENTICATE. |
Confirmations Required | CONFIRMATION_DETAILS | Get the AuthorisationRequired count per month. |
Confirmations Accepted by PSUs | CONFIRMATION_DETAILS | Get the Authorised count per month. |
Confirmations Rejected by PSUs | CONFIRMATION_DETAILS | Get the Rejected count per month. |
Template 4 - PSU Adoption (OBIE)
Required data point name | Table to refer | How to capture data |
---|
ReportMonth | The respective table you get the month from | Get the year-month values from the table. |
ASPSP Brand ID | N/A | A fixed value for a bank. |
Retail/Business PSUs | PSU_DETAILS, FIRST_TIME_USERS | The retail and business PSU details are available in the core banking system. The provided raw data tables include the PSU_IDs that can be used. |
PSUs used AIS Services for the first time | FIRST_TIME_USERS | The retail and business PSU details are available in the core banking system. The provided raw data tables include the PSU_IDs that used the AIS services for the first time. You can use the PSU_ID and get the PSU count that used the services for the first time in a particular month. |
PSUs used PIS Services for the first time | FIRST_TIME_USERS | The retail and business PSU details are available in the core banking system. The provided raw data tables include the PSU_IDs that used the PIS services for the first time. You can use the PSU_ID and get the PSU count that used the services for the first time in a particular month. |
Total PSUs used AIS Services | PSU_DETAILS | The retail and business PSU details are available in the core banking system. The provided raw data tables include the PSU_IDs that used the AIS services for the first time. You can use the PSU_ID and get the total PSU count that used the services for the first time in a particular month. |
Total PSUs used PIS Services | PSU_DETAILS | The retail and business PSU details are available in the core banking system. The provided raw data tables include the PSU_IDs that used the PIS services for the first time. You can use the PSU_ID and get the total PSU count that used the services for the first time in a particular month. |
Unique PSUs used both AIS and PIS Services for the first time | FIRST_TIME_USERS | The retail and business PSU details are available in the core banking system. The provided raw data tables include the PSU_IDs that used both AIS and PIS services for the first time. You can use the PSU_ID and get the PSU count that used the services for the first time in a particular month. |
Total unique PSUs used both AIS and PIS Services | PSU_DETAILS | The retail and business PSU details are available in the core banking system. The provided raw data tables include the PSU_IDs that used both AIS and PIS services for the first time. You can use the PSU_ID and get the total PSU count that used the services for the first time in a particular month. |
Template 5 - Payments Adoption (OBIE)
Required data point name | Table to refer | How to capture data |
---|
ReportMonth | The respective table you get the month from | Get the year-month values from the table. |
ASPSP Brand ID | N/A | A fixed value for a bank. |
Payment Type | Either UK.OBIE.BACS or UK.OBIE.CHAPS | This column value should be either UK.OBIE.BACS or UK.OBIE.CHAPS. |
PSU Authorisations for single Domestic Payments | or CHAPS_REQUEST_STATUS | Select the REQUEST_COUNT from relevant the payment type table where PAYMENT_TYPE = '/domestic-payment-consents' and AUTHORISATION_STATUS = 'Authorised' . |
Successful single Domestic Payments | BACS_REQUEST_STATUS or CHAPS_REQUEST_STATUS | Select the REQUEST_COUNT from the relevant payment type table where PAYMENT_TYPE = '/domestic-payment' and (AUTHORISATION_STATUS = 'AcceptedSettlementInProgress' or AUTHORISATION_STATUS = 'AcceptedSettlementCompleted'). |
Single Domestic Payments failed for Business Reasons | FAILED_BACS_REQUESTS or FAILED_CHAPS_REQUESTS | Get the sum of REQUEST_COUNT from the relevant payment type table where STATUS_CODE LIKE '%4%' . |
Single Domestic Payments failed for Technical Reasons | FAILED_BACS_REQUESTS or FAILED_CHAPS_REQUESTS | Get the REQUEST_COUNT from the relevant payment type table where STATUS_CODE = 500 . |
Single Domestic Payments Rejected | BACS_REQUEST_STATUS or CHAPS_REQUEST_STATUS | Select the REQUEST_COUNT from the relevant payment type table where (PAYMENT_TYPE = '/domestic-payment-consents' or PAYMENT_TYPE = '/domestic-payments' ) and AUTHORISATION_STATUS = 'Rejected' . |
Total payments included in Bulk/Batch files | FILE_PAYMENT | Get the TOTAL_PAYMENTS for the relevant payment type where LOCAL_INSTRUMENT = Payment Type . |
Successful International payments involving currency conversion | BACS_INTERNATIONAL or CHAPSS_INTERNATIONAL | The currency conversion details are available in the core banking system. The given tables provide all the successful international-payment details with the consent id for each payment type. |
Template 6 - TPP Volumes (OBIE)
Required data point name | Table to refer | How to capture data |
---|
ReportMonth | The respective table you get the month from | Get the year-month values from the table. |
ASPSP Brand ID | N/A | A fixed value for a bank. |
Total AISPs Registered (at 1st of month) |
| Zero for the starting month and for the following months the cumulative monthly number of AISPs registered of the last month. |
AISP Additions | AISP_VOLUMES | Get data from the AISP_COUNT column where STATUS='Registered' |
AISP Deregistrations | AISP_VOLUMES | Get data from the AISP_COUNT column where STATUS='Removed' . |
Cumulative Monthly number of AISPs |
| Use the following formula: (Total no of AISPs registered (at 1st of the month) + AISP Additions - AISP deregistrations)
|
Total PISPs Registered (at 1st of month) |
| Zero for the starting month and for the following months the cumulative monthly number of PISPs registered of last month. |
PISP Additions | PISP_VOLUMES | Get data from the PISP_COUNT column where STATUS='Registered' . |
PISP Deregistrations | PISP_VOLUMES | Get data from the PISP_COUNT column where STATUS='Removed' . |
Cumulative Monthly number of PISPs |
| Use the following formula: (Total no of PISPs registered (at 1st of month) + PISP Additions - PISP reregistrations)
|
Total CBPIIs Registered |
| Zero for starting the month and for the following months the cumulative monthly number of CBPIIs registered of last month. |
CBPII Additions | CBPII_VOLUMES | Get data from CBPII_COUNT column where STATUS='Registered' . |
CBPII Deregistrations | CBPII_VOLUMES | Get data from CBPII_COUNT column where STATUS='Removed' . |
Cumulative Monthly number of CBPIIs |
| Use the following formula: (Total CBPIIS Registered (at 1st of the month) + CBPII Additions - CBPII Deregistrations)
|
Template 7 - Daily Volumes (OBIE)
Required data point name | Table to refer | How to capture data |
---|
ReportDate | The respective table you get the data from | Get the year-month-date values from the table. |
ASPSP Brand ID | N/A | A fixed value for a bank. |
Endpoint ID | ENDPOINT_DETAILS | This value is a fixed value. you can get the resource from the respective table and map that with ENDPOINT_ID table. |
PCA API Calls | ACCOUNT_RAW_DATA_FOR_PCA_BCA, PAYMENT_RAW_DATA_FOR_PCA_BCA, FUNDS_RAW_DATA_FOR_PCA_BCA | The PCA/BCA details are available in the core banking system. The provided raw data tables include the ACCOUNT_ID of accounts that can be used to identify whether it's a PCA or BCA. |
BCA API Calls | ACCOUNT_RAW_DATA_FOR_PCA_BCA, PAYMENT_RAW_DATA_FOR_PCA_BCA, FUNDS_RAW_DATA_FOR_PCA_BCA | The PCA/BCA details are available in the core banking system. The provided raw data tables include the ACCOUNT_ID of accounts that can be used to identify whether it's a PCA or BCA. |
Successful API Calls (200, 201 or 204 codes) | STATUS_CODE_SUMMERY | The table contains the volume of API calls per status code per endpoint and per date. Filter the STATUS_CODE values of 200,201 and 204 per endpoint per day and get the sum of those. |
Failed API Calls Business Reasons (4xx Codes) | STATUS_CODE_SUMMERY | The table contains the volume of API calls per status code per endpoint and per date. Filter the STATUS_CODE values of 4xx per endpoint per day and get the sum of those. |
Failed API Calls Technical Reasons (5xx Codes) | STATUS_CODE_SUMMERY and AUTHORISATION_SUMMERY | The table contains the volume of API calls per status code per endpoint and per date. Filter the STATUS_CODE values of 5xx per endpoint per day and get the sum of those. |
API Calls Rejected Status | STATUS_CODE_SUMMERY | Get the sum of the above 2 values (Failed API Calls Business Reasons (4xx Codes) and Failed API Calls Technical Reasons (5xx Codes)) and add the value of Rejected statuses per endpoint per day from the AUTHORIZATION_SUMMERY table. |
TPPs Calling APIs | DIFFERENT_TPPS | The count of the DISTINCT_TPPS per elected resource per day. |
API Calls Not Authorised by PSU | AUTHORISATION_SUMMERY | The count of the Rejected status per endpoint per day. |
API Calls Authorised but Not Consumed | AUTHORISATION_SUMMERY | Get the count of Authorised status per endpoint per day and deduct the count of AcceptedStatementInProcess status per endpoint per day.
|
Multi Auth API Calls Successful | MULTI_AUTH_DETAILS | Get the count of Authorised statuses against /domestic-payment-consent per day. |
Multi Auth API Calls Failed | MULTI_AUTH_DETAILS | Get the count of Rejected statuses against
/domestic-payment-consent
per day. |
Configuring Data Reporting
The following sections explain how to configure Data Reporting:
Enabling Data Reporting
Follow the steps below to enable Data Reporting.
- Open
<WSO2_OB_APIM_HOME>/repository/conf/finance/open-banking.xml
and <WSO2_OB_KM_HOME>/repository/conf/finance/open-banking.xml
files. - Under the
<DataPublishing>
sub-element set the <Enabled>
parameter to true to enable the feature. - Replace the
<WSO2_OB_BI_HOST>
placeholder with the hostname of your WSO2 OB BI server and configure the other parameters accordingly.
<BIServer>
<DataPublishing>
<!-- Include all configurations related to Data publishing -->
<!-- Enable data publishing in WSO2 Open Banking-->
<Enabled>true</Enabled>
<!-- Server URL of the remote BI server used to collect statistics. Must
be specified in protocol://hostname:port/ format. -->
<ServerURL>{tcp://<WSO2_OB_BI_HOST>:7612}</ServerURL>
<!-- Administrator username to login to the BI server for data publishing. -->
<Username>admin@wso2.com@carbon.super</Username>
<!-- Administrator password to login to the BI server for data publishing. -->
<Password>wso2123</Password>
</DataPublishing>
</BIServer>
Configuring Open Banking Business Intelligence
Configuring databases
The following databases store raw and summarized data. Make sure they are available in your database servers.
- Configuring datasources
- Modify the
OB_REPORTING_DB
and OB_REPORTING_SUMMARIZED_DB
datasources in <WSO2_OB_BI_HOME>/conf/worker/deployment.yaml
file. - Update
jdbcUrl
, username
, password
and driverClassName
in the datasource entries with your database configurations. A sample is given below:
- name: OB_REPORTING_DB
description: The datasource used to store statistics for OB Reporting module
jndiConfig:
name: jdbc/OB_REPORTING_DB
definition:
type: RDBMS
configuration:
jdbcUrl: 'jdbc:mysql://localhost:3306/openbank_ob_reporting_statsdb?autoReconnect=true&useSSL=false'
username: 'root'
password: 'root'
driverClassName: 'com.mysql.jdbc.Driver'
maxPoolSize: 20
idleTimeout: 60000
connectionTestQuery: SELECT 1
# Use below for oracle database
# connectionTestQuery: SELECT 1 FROM DUAL
validationTimeout: 30000
isAutoCommit: false
- name: OB_REPORTING_SUMMARIZED_DB
description: The datasource used to store statistics for OB Reporting module
jndiConfig:
name: jdbc/OB_REPORTING_SUMMARIZED_DB
definition:
type: RDBMS
configuration:
jdbcUrl: 'jdbc:mysql://localhost:3306/openbank_ob_reporting_summarizeddb?autoReconnect=true&useSSL=false'
username: 'root'
password: 'root'
driverClassName: 'com.mysql.jdbc.Driver'
maxPoolSize: 20
idleTimeout: 60000
connectionTestQuery: SELECT 1
# Use below for oracle database
# connectionTestQuery: SELECT 1 FROM DUAL
validationTimeout: 30000
isAutoCommit: false
Data Reporting API
If you're using a customised consent authentication web application, you may use the Data Reporting API to publish events from the application. Invoke the Data Reporting API in all the relevant places to publish the PSU and authorisation data to the reporting databases.
In the following scenarios, events are captured using the consent authorisation web app:
- The user visiting the consent page
- After the user authorising/denying the consent
For sample requests, see Data Reporting API.
Capturing data during invocation failure scenarios
- Go to the
<WSO2_OB_APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences
directory. Create an XML file named api_invocation_fail_data_publisher.xml
with the following content:
<sequence name="_api_invocation_fail_data_publisher_"
xmlns="http://ws.apache.org/ns/synapse">
<property name="error_message_type" value="application/xml"/>
<class name="com.wso2.finance.open.banking.management.information.reporting.data.publisher.OBErrorDataPublisher"/>
</sequence>
Open the <WSO2_OB_APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences/_throttle_out_handler_.xml
file and add the
OBErrorDataPublisher
class under the sequence
tag.
<class name="com.wso2.finance.open.banking.management.information.reporting.data.publisher.OBErrorDataPublisher"/>
Open the <WSO2_OB_APIM_HOME>/repository/deployment/server/synapse-configs/default/sequences/_auth_failure_handler_.xml
file and add the
OBErrorDataPublisher
class below the sequence key
element as shown below:
<sequence key="_cors_request_handler_"/>
<class name="com.wso2.finance.open.banking.management.information.reporting.data.publisher.OBErrorDataPublisher"/>