DATA PROTECTION
The data protection contains following:
- Personally Identifiable Information
- Flow of PII Data
- Administration of PII Data
- Deleting or Purging PII data
- Masking of PII data
- Access Control for Audit Information
Personally Identifiable Information (PII)
Personally identifiable information (PII) is any data that could potentially identify a specific individual. Any information that can be used to distinguish one person from another and can be used to de-anonymizing anonymous data can be considered PII.
OBDX needs to acquire, use or store some PII data of the customers of the Bank in order to perform its desired services. This section declares the PII data captured by OBDX so that the Bank is aware of the same and adopts necessary operational procedures and checks in order to protect PII data in the best interest of its customers
Fields |
OBDX 18.1 |
---|---|
Bank account information |
Yes |
Beneficiaries |
Yes |
Biometric records |
No |
Birthplace |
No |
Bonus |
No |
Country, state, or city of residence |
Yes |
Credit card numbers |
Yes |
Date of birth |
Yes |
Digital identity |
No |
Disability leave |
No |
Driver's license number |
Yes |
Education history |
No |
Email address |
Yes |
Emergency contacts |
No |
Employee ID |
Yes |
Ethnicity |
No |
Financial information and accounts |
Yes |
Fingerprints |
No |
Full name |
Yes |
Gender |
Yes |
Genetic information |
No |
Health information (including conditions, treatment, and payment) |
No |
Healthcare providers and plans |
No |
Personal/office telephone numbers |
Yes |
IP address |
No |
Job title |
Yes |
Login name |
Yes |
MAC address |
Yes |
Marital status |
Yes |
Military rank |
No |
Mother's maiden name |
No |
National identification number |
Yes |
Passport number |
Yes |
Performance evaluation |
No |
Personal phone number |
Yes |
Photographic images |
No |
PIN numbers |
Yes |
Political affiliations |
No |
Property title information |
No |
Religion |
No |
Salary |
Yes |
Screen name |
No |
Sexual lif |
No |
Taxpayer information |
Yes |
Union membership |
No |
Vehicle registration number |
Yes |
Work telephone |
Yes |
Citizenship Number |
No |
Geo-Location |
No |
Product has Customer defined fields |
No |
Mobile Subscriber Identifier (IMSI) |
No |
Surname |
Yes |
First name |
Yes |
Flow of PII Data
This section depicts the flow ‘personally identifiable information’ (PII) within the OBDX system in the form of a data flow diagram.
- The Bank Administrator is Bank’s employee who is performing administrative functions using OBDX. As part of these, he will be dealing with PII data. An example is that the Administrator creates Retail and Corporate users in OBDX and while creating users he/she enters user information such as first name, last name, email address, mobile number, correspondence address etc.
- Retail / Corporate Customer is Bank’s customer who is accessing the online banking features. As part of this he/she will be able to see his/her accounts, balances, beneficiaries, transactions, profile details etc. Note that OBDX also supports onboarding of new users. The system captures some user information such as first name, last name, email address, mobile number, correspondence address and financial information such as income profile.
- DBA / Bank IT Staff is Bank’s employee who is not a user of OBDX but has access to the database that stores OBDX bank end data or the server environments on which OBDX is deployed.
- Web server typically contains static web content such as styling information (CSS), Javascript resources, images, static HTMLs etc. Web server passes the REST service calls to Application server.
- Application (App) Server is the server on which OBDX services are deployed. This server performs required processing on the service calls. It does use the database for retrieval or storage of data. It can also connect to external user credential store (such as OUD or Open LDAP). It can also connect to core product processor to enquiring CIF or Account related data or for posting any transactions initiated by the Retail or Corporate customer.
- Database is the persistence store for OBDX. It can contain master configuration data, user data and transactional data.
- OUD / LDAP represents the external user credentials store. OBDX does not maintain user credentials locally but depends on external specialized software to do that. An example can be Oracle Unified Directory (OUD) or Open LDAP.
- Product Processor is the core banking solution which actually processes actual banking transactions. OBDX connects to the product processor to fetch data such as CIFs or Accounts or transactions. It also connects to the product processor to post new transaction initiated by Retail or Corporate customer.
Administration of PII Data
This section provides information about doing administrative tasks on PII data. This includes retrieval, modification, deletion or purging of such data.
Extracting PII data
OBDX stores some PII data in its database and it also accesses data stored or owned by external systems such as OUD / LDAP or product processor.
Data stored in OBDX
This section provides information about the tables that store PII data. This information is useful for the Bank to extract PII information.
PII Data |
Table |
---|---|
Bank account information |
DIGX_AC_ACCOUNT_NICKNAME DIGX_AM_ACCOUNT_ACCESS DIGX_AM_ACCOUNT_EXCEPTION |
Beneficiaries |
DIGX_PY_PAYEEGROUP DIGX_PY_PAYEE DIGX_PY_DOMESTIC_UK_PAYEE DIGX_PY_INTERNAL_PAYEE DIGX_PY_DEMANDDRAFT_PAYEE DIGX_PY_INTNATNL_PAYEE_BNKDTLS DIGX_PY_DOMESTIC_INDIA_PAYEE DIGX_PY_PEERTOPEER_PAYEE DIGX_PY_INTERNATIONAL_PAYEE DIGX_PY_DOMESTIC_SEPA_PAYEE DIGX_PY_GLOBAL_PAYEE |
Country, state, or city of residence |
DIGX_OR_APPLICANT, DIGX_OR_APPLICANT_ADDRESS DIGX_UM_USERPROFILE |
Credit card numbers |
DIGX_CD_CREDITCARD_MASTER DIGX_CD_SUPP_CARD_RELATION |
Date of birth |
DIGX_OR_APPLICANT DIGX_UM_USERPROFILE |
Driver's license number |
DIGX_OR_APLT_IDNT |
Email address |
DIGX_OR_APPLICANT_CONTACT DIGX_OR_EMAIL_VERIFICATION (used only for email verification, data is purged once email is verified) DIGX_UM_USERPROFILE |
Employee ID |
DIGX_OR_APLT_EMPT |
Financial information and accounts |
Only financial information(Income, Asset, expense, Liability) DIGX_OR_APLT_FIN_INCM, DIGX_OR_APLT_FIN_AST, DIGX_OR_APLT_FIN_EXP, DIGX_OR_APLT_FIN_LIB |
Full name |
DIGX_OR_APPLICANT DIGX_UM_USERPROFILE |
Gender |
DIGX_OR_APPLICANT |
Personal/office telephone numbers |
DIGX_OR_APPLICANT_CONTACT DIGX_UM_USERPROFILE |
Job title |
DIGX_OR_APLT_EMPT DIGX_UM_USERPROFILE |
Login name |
DIGX_UM_USERAPPDATA DIGX_UM_USERPARTY_RELATION USERS GROUPMEMBERS DIGX_UM_USERPROFILE DIGX_AM_ACCOUNT_ACCESS |
MAC address |
DIGX_AUDIT_LOGGING |
Marital status |
DIGX_OR_APPLICANT |
National identification number |
DIGX_OR_APLT_IDNT |
Passport number |
DIGX_OR_APLT_IDNT |
Personal phone number |
DIGX_OR_APPLICANT_CONTACT |
PIN numbers |
DIGX_OR_APPLICANT_ADDRESS |
Salary |
DIGX_OR_APLT_FIN_INCM, DIGX_OR_APLT_EMPT |
Social security number |
DIGX_OR_APLT_IDNT |
Taxpayer information |
DIGX_OR_APLT_IDNT |
Vehicle registration number |
DIGX_OR_APLT_IDNT |
Work telephone |
DIGX_OR_APPLICANT_CONTACT |
Surname |
DIGX_OR_APPLICANT DIGX_UM_USERPROFILE |
First name |
DIGX_OR_APPLICANT DIGX_UM_USERPROFILE |
Please note that OBDX provides user interface to access most of this data. The data will be accessible to you only if you have required roles and policies mapped to your OBDX login. For example, an AdministratorAdministrator is a set of individuals that administer the applicant/Affiliate entity. For example, Accountants, Authorized Signatories for organizations, Power of Attorney for individuals. user can see retail user’s profile only if he is entitled by a policy to access this information.
Data stored outside OBDX
OBDX can store user information in external systems such as OUD or LDAP. OBDX provides screens for fetching this data. Please refer to the ‘User Management’ section of the Core user manual of OBDX. Web help is also available at https://docs.oracle.com/cd/E92727_01/webhelp/OBDX.htm#obdx/core/coreintro.htm
Also note that the data can be accessed directly from the external system i.e. OUD, Open LDAP or the ProductA product is created based on the bank's business requirements and has certain typical parameters that describe its attributes or characteristics. Every product is defined under Product Class and Product Group.
For example, a product 'Fixed rate home loan' is defined under product group 'Home Loan' and product class 'Loans'. Processor. These details are outside the scope of this document. Please refer to the manual of corresponding software for more details.
Deleting or Purging PII data
There are two ways in which PII data can be deleted or purged from the system.
Using User Interface
The information created in (or owned by) OBDX can be deleted from its user interface. For example, a retail user can delete the beneficiaries he/she has maintained. Please refer to ‘Manage Payee’ section of following user manual for more details.
https://docs.oracle.com/cd/E92727_01/webhelp/OBDX.htm#obdx/retail/payments/managepayees.htm%3FTocPath%3DOracle%2520Banking%2520Digital%2520Experience%7CRetail%2520Servicing%7CPayments%7C_____1
Note that user’s data such as CIFCustomer Information File or account number is not owned by OBDX and hence it cannot be deleted from OBDX. However information such as account access granted to a particular user can be modified or deleted by the bank administrator. Please refer to ‘Party
A party is any individual or business entity having a banking relationship with the bank. Account Access’ and ‘User Account Access’ sections of the Core user manual for more details.
https://docs.oracle.com/cd/E92727_01/webhelp/OBDX.htm#obdx/core/accountaccess/acctaccesintro.htm%3FTocPath%3DOracle%2520Banking%2520Digital%2520Experience%7CCore%7CAccount%2520Access%7C_____0
Using scheduled purge procedures
OBDX provides some out of the box purge procedures that can be scheduled to purge the data. Otherwise the DBA / IT staff can prepare similar procedures to purge required data. However note that it is not recommended to purge or delete any data stored in OBDX tables without doing detailed impact analysis. Please also note that the scheduled purge jobs are useful typically for purging old data. They may not be useful for purging data of a specific customer.
Manual truncation of data from backend
In scenarios where OBDX does not have user interface to remove customer data and scheduled purge option is not useful, then data needs to be purged using SQL scripts. Below section provides some queries that can be used for such a purging. This option must be used with utmost care and proper impact analysis must be done before using these scripts
PII Data |
Table |
Script |
---|---|---|
For modules other than Origination: Personal information of user including Country, state, or city of residence, Date of birth, Email address, Employee ID, Full name, Gender, Personal/office telephone numbers, Login name, Work telephone, First Name, Surname
|
USERS GROUPMEMBERS DIGX_UM_USERPROFILE DIGX_UM_USERAPPDATA DIGX_UM_USERPARTY_RELATION |
delete from digx_um_userparty_relation where user_id = ‘<USER IDENTIFIER>’; delete from digx_um_userappdata where id = ‘<USER IDENTIFIER>’; delete from DIGX_UM_USERPROFILE where U_NAME = ‘<USER IDENTIFIER>’; delete from GROUPMEMBERS where G_MEMBER = ‘<USER IDENTIFIER>’; delete from USERS where U_NAME = ‘<USER IDENTIFIER>’; |
Bank Account Information |
DIGX_AC_ACCOUNT_NICKNAME DIGX_AM_ACCOUNT_ACCESS DIGX_AM_ACCOUNT_EXCEPTION |
delete from DIGX_AC_ACCOUNT_NICKNAME where USER_ID = <USER IDENTIFIER>; delete from DIGX_AM_ACCOUNT_EXCEPTION where ACCOUNT_ACCESS_ID in (select ACCOUNT_ACCESS_ID from DIGX_AM_ACCOUNT_ACCESS where ACCESS_LEVEL = ‘USER’ and USERID = <USER IDENTIFIER>); delete from DIGX_AM_ACCOUNT_ACCESS where ACCESS_LEVEL = ‘USER’ and USERID = <USER IDENTIFIER>; |
Beneficiaries |
DIGX_PY_PAYEEGROUP DIGX_PY_PAYEE DIGX_PY_DOMESTIC_UK_PAYEE DIGX_PY_INTERNAL_PAYEE DIGX_PY_DEMANDDRAFT_PAYEE DIGX_PY_INTNATNL_PAYEE_BNKDTLS DIGX_PY_DOMESTIC_INDIA_PAYEE DIGX_PY_PEERTOPEER_PAYEE DIGX_PY_INTERNATIONAL_PAYEE DIGX_PY_DOMESTIC_SEPA_PAYEE |
delete from DIGX_PY_INTERNAL_PAYEE where PAYEE_ID in (select PAYEE_ID from DIGX_PY_PAYEE where CREATED_BY = <USER IDENTIFIER>); delete from DIGX_PY_DOMESTIC_UK_PAYEE where PAYEE_ID in (select PAYEE_ID from DIGX_PY_PAYEE where CREATED_BY = <USER IDENTIFIER>); delete from DIGX_PY_DEMANDDRAFT_PAYEE where PAYEE_ID in (select PAYEE_ID from DIGX_PY_PAYEE where CREATED_BY = <USER IDENTIFIER>); delete from DIGX_PY_INTNATNL_PAYEE_BNKDTLS where PAYEE_ID in (select PAYEE_ID from DIGX_PY_PAYEE where CREATED_BY = <USER IDENTIFIER>); delete from DIGX_PY_INTERNATIONAL_PAYEE where PAYEE_ID in (select PAYEE_ID from DIGX_PY_PAYEE where CREATED_BY = <USER IDENTIFIER>); delete from DIGX_PY_DOMESTIC_INDIA_PAYEE where PAYEE_ID in (select PAYEE_ID from DIGX_PY_PAYEE where CREATED_BY = <USER IDENTIFIER>); delete from DIGX_PY_PEERTOPEER_PAYEE where PAYEE_ID in (select PAYEE_ID from DIGX_PY_PAYEE where CREATED_BY = <USER IDENTIFIER>); delete from DIGX_PY_DOMESTIC_SEPA_PAYEE where PAYEE_ID in (select PAYEE_ID from DIGX_PY_PAYEE where CREATED_BY = <USER IDENTIFIER>); delete from DIGX_PY_PAYEE where CREATED_BY = <USER IDENTIFIER>; delete from DIGX_PY_PAYEEGROUP where CREATED_BY = <USER IDENTIFIER>; |
Credit Card Information |
DIGX_CD_CREDITCARD_MASTER DIGX_CD_SUPP_CARD_RELATION |
delete from DIGX_CD_SUPP_CARD_RELATION where PRIMARYCARDNUMBER in (select ID from DIGX_CD_CREDITCARD_MASTER where PARTY_ID = <PARTY IDENTIFIER>); delete from DIGX_CD_CREDITCARD_MASTER where PARTY_ID = <PARTY IDENTIFIER>; |
Party/User Information in Originations |
DIGX_OR_APPLICANT DIGX_OR_APPLICANT_ADDRESS DIGX_OR_APLT_IDNT DIGX_OR_APPLICANT_CONTACT DIGX_OR_EMAIL_VERIFICATION DIGX_OR_APLT_EMPT DIGX_OR_APLT_FIN_INCM DIGX_OR_APLT_FIN_AST DIGX_OR_APLT_FIN_EXP DIGX_OR_APLT_FIN_LIB |
delete from DIGX_OR_APLT_FIN_INCM where APPLICANT_ID = '<APPLICANT IDENTIFIER>'; delete from DIGX_OR_APLT_FIN_AST where APPLICANT_ID = '<APPLICANT IDENTIFIER>'; delete from DIGX_OR_APLT_FIN_EXP where APPLICANT_ID = '<APPLICANT IDENTIFIER>'; delete from DIGX_OR_APLT_FIN_LIB where APPLICANT_ID = '<APPLICANT IDENTIFIER>'; delete from DIGX_OR_APLT_EMPT where APPLICANT_ID = '<APPLICANT IDENTIFIER>'; delete from DIGX_OR_APLT_IDNT where APPLICANT_ID = '<APPLICANT IDENTIFIER>'; delete from DIGX_OR_APPLICANT_CONTACT where APPLICANT_ID = '<APPLICANT IDENTIFIER>'; delete from DIGX_OR_EMAIL_VERIFICATION where SUBMISSION_ID = '<SUBMISSION IDENTIFIER>'; delete from DIGX_OR_APPLICANT_ADDRESS where APPLICANT_ID = '<APPLICANT IDENTIFIER>'; delete from DIGX_OR_APPLICANT where PARTY_ID = '<PARTY IDENTIFIER>'; |
Masking of PII data
OBDX framework provides a facility to mask user sensitive information before showing on the screen. Masking is a process in which only some portion of the data is displayed to the user while remaining portion of the data is either skipped or is replaced with hash characters such as ‘*’. Main purpose of masking is to avoid a possibility of ‘over the shoulder’ stealing of sensitive information. However it is also used so that the clear text sensitive information is not logged in system logs.
A typical example of masking is the account numbers. When OBDX API is invoked that contains Account number is the response, the API will always give masked value. So complete clear text account number is never displayed on the screen.
OBDX provides masking for following fields out of the box.
OBDX framework also provides a provision in which any field other can the ones mentioned in above table can also be masked as per the requirement. This can be achieved by following steps:
- Create a complex datatype in OBDX. This datatype must extend com.ofss.digx.datatype.complex. MaskedIndirectedObject
- Define a ‘masking qualifier’ and a ‘masking attribute’
- Configure this masking qualifier and masking attribute in DIGX_FW_CONFIG_ALL_B. An example of the configurations for account number mask is given below
INSERT INTO digx_fw_config_all_b (PROP_ID, CATEGORY_ID, PROP_VALUE, FACTORY_SHIPPED_FLAG, PROP_COMMENTS, SUMMARY_TEXT, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATED_DATE, OBJECT_STATUS, OBJECT_VERSION_NUMBER)
VALUES ('*.account_id', 'Masking', 'AccountNumberMasking<', 'Y', null, null, 'ofssuser', sysdate, 'ofssuser', sysdate, 'A', 1);
INSERT INTO digx_fw_config_all_b (PROP_ID, CATEGORY_ID, PROP_VALUE, FACTORY_SHIPPED_FLAG, PROP_COMMENTS, SUMMARY_TEXT, CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATED_DATE, OBJECT_STATUS, OBJECT_VERSION_NUMBER)
VALUES ('AccountNumberMasking', 'MaskingPattern', 'xxxxxxxxxxxxNNNN', 'Y', null, null, 'ofssuser', sysdate, 'ofssuser', sysdate, 'A', 1);
With above steps, the OBDX framework will make sure to mask the data of this data type during serialization phase in the REST tier.
The masking pattern can contain following characters
- N – Original character in the data will be retained
- H – Original character in the data will be skipped
- * (Or any other placeholder character) – Original character in the data will be replaced with this character
Access Control for Audit Information
OBDX provides mechanism for maintaining audit trail of transactions / activities done by its users in the system. This audit trail is expected to be used for customer support, dispute handling. It can also be used for generating some management reports related to feature usage statistics etc.
From a data protection perspective it is worth noting that the audit trail contains PII data in the form of transactional data as well as usage trends or statistics. Hence it is necessary for the Bank to put in place appropriate access control mechanisms so that only authorized Bank employees get access to this data. OBDX provides comprehensive access control mechanism that the Bank can leverage to achieve this.
This access control can be achieved using the role based transaction mapping. This section focuses specifically from data protection aspect. You are requested to go through the user manual for ‘Role Transaction Mapping’ before reading further in this section. As an example, we have considered a use case where the Bank wants to restrict access to ‘Audit Log’ feature so that only the permitted set of administration users will be able to access audit of the users. Please note that same process can be applied to other services that deal with PII data. For example, same process can be used for restricting access to user management functions.
Check the ‘out of box’ access granted
- Login to OBDX as Administrator
- On dashboard, click on ‘Role Transaction Mapping’
- Click on Policy Domain ‘Admin’.
- In ‘Resource Name’ field, input the Audit service name com.ofss.digx.app.audit.service.Audit and click on ‘Search’
- You will see a list of policies. Check the Application roles mapped in each of these policies. The users of these roles will get access to View Audit Log feature.
- You can delete these policies or remove the required application roles from these policies to restrict access of ‘View Audit Log’ feature from users of those roles. Please refer to the ‘Edit Policy’ and ‘Delete Policy’ sections of the Core user manual https://docs.oracle.com/cd/E83887_01/PDF/UserManual/User%20Manual%20Oracle%20Banking%20Digital%20Experience%20Core.pdf for more details.
Below sections describe the steps required to grant the audit log access to restricted set of users
Create Enterprise Role
- Login to OUD and navigate to Data Browser. In the left panel, expand Groups section. This will show you the existing enterprise roles in the system. For example, below screen shows that the ‘Administrator’ group has ‘AdminMaker’, ‘AdminChecker’ and ‘AuthAdmin’ as member groups.
- Create new Group by clicking on the menu option in left panel as shown in below screen.
- Provide name to the new group. Below image shows a group ‘AuditLogViewer’ created.
- Under ‘Member Information’ section, click on the ‘Add’ icon to add required users to this group. Below screen shows a user ‘adminuser1’ added to the group
- Click on ‘Create’ button present at top right corner of the screen to create this group
- Click on ‘Attributes’ section of the group. Under ‘Mandatory Attributes’, click on the ‘Add’ button for ‘Object Class’. Object class picker window will appear. Select the ‘fcRole’ object class from this window.
- Under ‘Optional Attributes’, add a new attribute with name ‘fcroleid’ and value as ‘EMPLOYEE’.
- Click on ‘Ok’ button.
- Click on ‘Apply’ button.
- Add the newly created group as member of the ‘Administrator’ group. For this, select the ‘Administrator’ group from left panel. Go to the ‘Member Information’ section and click on ‘Add’ icon. Now select the newly created group from the available list and click on ‘Select’
- Click on ‘Apply’ on the main screen.
Map users to Enterprise Role
Users can be mapped to the new Enterprise role from OUD as mentioned in point 4 in previous section. Alternatively, OBDX also provides screens for creating users and modifying them which can be used to map the newly created role to users. Please refer to ‘User Management’ section of following document for more details on user management.
https://docs.oracle.com/cd/E92727_01/webhelp/OBDX.htm#obdx/core/usermgmnt/usermgmnt.htm%3FTocPath%3DOracle%2520Banking%2520Digital%2520Experience%7CCore%7C_____11
Here the newly created role ‘AuditLogViewer’ will be visible to you for mapping to user as shown in below screen.
Create Application Role
Next step is to create an application role and map newly created enterprise role to this application role.
Please refer to the https://docs.oracle.com/cd/E92727_01/webhelp/OBDX.htm#obdx/core/roletxnmapping/applicationrole.htm for more details on the same.
Create Resource
A resource represents specific function performed by the system. A resource is identified by fully qualified service and its method name. For example, the resource for searching audit log is com.ofss.digx.app.audit.service.Audit.search. If this resource is not already present in the system then, it can be created by the administrator. Please refer to the ‘Application Resource’ section of https://docs.oracle.com/cd/E92727_01/webhelp/OBDX.htm#obdx/core/roletxnmapping/applicatnresource.htm%3FTocPath%3DOracle%2520Banking%2520Digital%2520Experience%7CCore%7CRole%2520Transaction%2520Mapping%7C_____2 for more details on the same.
Create Policy
Once the application role and resource are created then they can be added to an existing policy or can be added to a new policy. Please refer to the ‘Authorization – Policy’ section of https://docs.oracle.com/cd/E92727_01/webhelp/OBDX.htm#obdx/core/roletxnmapping/policydomain.htm%3FTocPath%3DOracle%2520Banking%2520Digital%2520Experience%7CCore%7CRole%2520Transaction%2520Mapping%7C_____4 for more details on the same.
Once policy is created, users who are mapped to the application role get access to the resource mapped under the same policy.