Example of a multibanking configuration

Assume that you want to configure a simple multibanking environment based on the hierarchy shown in Sample bank hierarchy, and that this environment contains a single application with the following current version information:

Table 1. Example of an APP_VERSION table
ID	VERSION	APPLICATION_ID
1000	1.0.0	1

To configure such an environment:

Define, in the PARTY table, a list of involved parties that reflects the bank hierarchy, as shown in Table 2. Each party has its own ID. It is possible to traverse the hierarchy using the ID and PARTY_ID attributes of each record. The APP_VERSION_ID of each party in this table is 1000, so all parties are associated with the same application version (with APPLICATION_ID 1 and VERSION 1.0.0).
Create a security structure that allows each party to view only the operational data that it should be allowed to view. This requires creating records in the GRP_RES_PERM_REL and RES_PERM tables, as shown in (see Table 3 and Table 4:
- GRP_RES_PERM_REL specifies:
  GROUP_NAME
  
  Each group name is defined in the system authentication repository.
  
  RESPERM_ID
  
  This attribute connects the group to an entry in the RES_PERM table. where resources and permissions are defined.
  
  APP_ID
  
  This attribute specifies the application to which the resources permissions are granted.
  
  Note: All users of the FTM GUI must be members of the group FTMUser. Therefore, it is recommended that multibanking view permissions not be assigned to this group. Otherwise, these permissions would be granted to all users, including users who are added in the future.
- RES_PERM specifies:
  ID
  
  A resource permission identifier. This is used to link a resource permission to a GRP_RES_PERM_REL record.
  
  RESOURCE_TYPE
  
  The type of resource to which the permission applies.
  
  RESOURCE
  
  The parties affected by this permission. Ensure that the specified party IDs belong to the application defined by APP_ID in the GRP_RES_PERM_REL table.
  
  PERMISSION
  
  The type of permission. In this example, View is the only possible value.
The following fields correlate groups with an application and permissions:
- RESPERM_ID in the GRP_RES_PERM_REL table
- ID in the RES_PERM table

Table 2. Example of a multibanking environment PARTY table
ID	APP_VERSION_ID	PARTY_ID	NAME
100	1000	Null	BankA
200	1000	Null	BankB
300	1000	Null	BankC
120	1000	100	CorporateA1
130	1000	100	CorporateA2
121	1000	120	DepartmentA11
122	1000	120	DepartmentA12

Table 3. Example of a multibanking environment GRP_RES_PERM_REL table
GROUP_NAME	RESPERM_ID	APP_ID
FTMUser	1	1
FTMAdmin	2	1
BankAUser	100	1
BankBUser	200	1
BankCUser	300	1
CorpA1User	120	1
CoprA2User	130	1
DepartmentA11User	121	1
DepartmentA12User	122	1

Table 4. Example of a multibanking environment RES_PERM table
ID	RESOURCE_TYPE	RESOURCE	PERMISSION
1	GUI	Channel	View
2	DATA_PARTY_ALL	all-data	View
100	DATA_PARTY_TREE	100	View
200	DATA_PARTY_TREE	200	View
300	DATA_PARTY_TREE	300	View
120	DATA_PARTY_TREE	120	View
130	DATA_PARTY_TREE	130	View
121	DATA_PARTY	121	View
122	DATA_PARTY	122	View

The data in these tables specifies that:

Users who belong to the group DepartmentA11User cannot see the data that belongs to the group DepartmentA12User, and vice versa.
Users who belong to the group DepartmentA11User or DepartmentA12User cannot see the data that belongs to their parent entity, CorpA1User.
Users who belong to the group CorpA1User can see their own data and the data that belongs to DepartmentA11User and DepartmentA12User, but not the data that belongs to CorpA2User, or to any other entity that is situated higher in the hierarchy.
Users who belong to one of the groups BankAUser, BankBUser, or BankCUser can access only data from their own hierarchies, not data from other hierarchies.
Each group affects a given party, and that the relationship is the same as the one that is shown in Sample bank hierarchy.
All of the permissions to parties, as for other resources, are tied to a specific application.

Only users who belong to FTMAdmin have access to all operational data.

This example uses simple 1:1 relationships (one group associated with one RES_PERM related to one party related to one application). However, a single group might have several RES_PERM entries. For information about using more than one application and how to scale resource permissions, see OAC Security Data Model.

Figure 1. Sample bank hierarchy