Tech Guides

Persistent Entities in openg2p-spar-mapper-api

id_fa_mappings

Contains the records for id_value (beneficiary Id) and fa_value (Financial Address) mapping

Column	Description
id_value	This is the Beneficiary ID - that will travel in the G2P Chain. This the beneficiary id for which the upstream PBMS / MIS platforms will create disbursements The id_value is constructed using a construction strategy (decided based on implementation). If the mapper is maintained using the self service paradigm, one of the ways that you can construct the ID Value is using the "auth" attributes from the Login Provider. An OIDC / OAuth2.0 Login provider usually provides the following attributes sub - Subject. Usually the ID/Token of the Beneficiary iss - Issuer URL name - Name of Beneficiary email - Email of Beneficiary phone_number - Phone Number of Beneficiary If we decide that the Banks update the Mapper, then a suitable construction strategy needs to be arrived at.
fa_value	This is the Financial Address of the Beneficiary - Usually will represent the Savings/ Checking /Current account of the beneficiary in a Bank. The fa_value should be the full account details, such that this value alone is sufficient to enable a payment transaction into the account using the National Clearing Network.
name	The name of the beneficiary. It is a good idea to have the name of the beneficiary travel back to the upstream systems as part of the "disbursement settlement status" -- The Disbursement settlement status should be sent by the final destination bank (where the beneficiary is credited).
phone	Phone number of the beneficiary
additional_info	This is an extensibility feature - to store additional attributes required in an implementation. The SPAR Self Service - populates this column with the strategy-Id (specifies the strategy used for constructing the fa_value)

Persistent Entities in openg2p-spar-self-service-api

dfsp_level and dfsp_level_values - are static tables that contain the information pertaining to the Banks (and other financial service providers), their branches. The use of these two tables are explained below using examples

dfsp_levels

id	name	level_type - ENUM	parent
1	Bank	bank	0
2	Branch	branch	1
3	Account number	account	2

The above data indicates that, to fully express the Financial Address of a Beneficiary's bank account, the self service platform needs to capture 3 attributes for the Financial Address, viz. Bank, Branch & Account

Similarly for a Mobile Number based Wallet, we can think of the following dfsp_level configuration

id	name	level_type - ENUM	parent
4	Mobile Wallet Service Provider	mobile_wallet_provider	0
5	Mobile number	mobile_number	5

For a Email Address based Wallet, we can have the following dfsp_level configuration

id	name	level_type - ENUM	parent
6	Email Wallet Service Provider	email_wallet_provider	0
7	Email address	email_address	6

The self-service-ui uses the api - "get_levels (parent)" to paint the UI fields to capture the input for these attributes - parent = 0, will provide the first level for the FA hierarchy

Self Service UI - showing capture of FA information

dfsp_level_values

For facilitating capture of a Bank Account, we can visualize the following dfsp_level_values configuration

id	name	code	parent	level_id
1	Bank One	Bank001	0	1
2	Bank Two	Bank002	0	1
3	Bank Three	Bank003	0	1

The API - get_level_values (parent = 0, level_id = 1) - will yield the UI a drop down of these 3 banks.

id	name	code	parent	level_id
1	Branch 001	Branch001-Bank001	1	2
2	Branch 002	Branch002-Bank001	1	2
3	Branch 003	Branch003-Bank001	1	2

The API - get_level_values (parent = 1, level_id = 2) - will yield the UI a drop down of these 3 branches for Bank One

login_providers

id	name	login_button_image_url	authorization_parameters	strategy_id
1	E-Signet	The Image that can be shown on the UI for E-Signet		1
2	Keycloak			2

The API - get_login_providers - will provide the list of configured login_providers. The UI can then redirect itself to the redirect_url specified for that login_provider for the necessary authentication.

strategy

This table contains the construction and deconstruction strategies to be used for id_value and fa_value - that will be eventually stored in the mapper.

The strategy ID is mapped to the login_provider for ID Strategy.

The strategy ID is mapped to the dfsp_levels for FA Strategy.

Many Banks (and possibly all Banks) may use the same FA Strategy. Similarly, all mobile wallet providers may use a single FA Strategy (different from Banks).

Some examples of construction and de-construction strategies are as follows

ID - Construction Strategy --

ID - Deconstruction Strategy --

FA - Construction Strategy --

FA - Deconstruction Strategy --

APIs

Refer to Stoplight API documentation