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
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
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
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
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
dfsp_level_values
For facilitating capture of a Bank Account, we can visualize the following dfsp_level_values configuration
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.
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
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 API Reference.
Last updated
