Financial Address Mapper as a DPI component for countries

[vvujjini]

As governments explore efficient ways to reach out to it's beneficiaries and delivery social assistance in cash, reaching the intended beneficiary financial store of value account (could be a bank account, mobile wallet, loading a pre paid card, etc) to make quick transfers becomes an important building block in Govt to Person (G2P) Payments context. There is good amount of demand in this space and having this Financial Address Mapper registry / module as as a self sustaining building block for quick demonstration and eventually adoption with in countries.

This registry of Beneficiary ID to Financial Address in normative forms will enable govt departments spread across various sectors (pensions, education, health, social welfare, etc.,) to access this registry for transfers. From Beneficiary perspective, she can easily manage one or more accounts and control flow of benefits instead of managing the linkages across various department apps/services.

More detailed visualisation of this high level solution blueprint is here

Additionally, how Financial Address Mapper interacts with various other solutions in the larger social assistance use cases can be found here

Epic Store: "Implementing Financial Address Mapper registry"

In first phase:

1. Simple Postman interface complaint to G2P Connect Financial Address Mapper specs to implement link, unlink, resolve, txn/search interfaces
2. Above G2P Connect interfaces to be wrapped with underlying registry APIs to manage the above crud operations.
3. Registry design to hold ID, Name, Mapper Id, status, Mobile Number (optional) + basic auditable columns. IDs shall be stored in normative form as defined in G2P connect specs.
4. Release the Financial Address Mapper registry with starter kit and minimal documentation on CDPI Living Lab (AWS account).

In subsequent phases:

1. Adding API end point security to G2P Connect and underlying registry APIs to secure who can access the end points.
2. Ensuring beneficiary consent and authentication before making edits to the mapper.
3. Simple UX layer to manage basic operations of ID Mapper from beneficiary and policy maker point of views.
4. Capability to store additional information as key/value pairs.
5. ID mapper owner and Policy makers having visibility to out of box audibility and analytical capabilities of a registry.
6. Generalising the building block for other domains like health, education etc., use cases with custom validation on normative IDs.
7. Workflow requirements shall include as an e.g., authentication of beneficiary before making changes to mapper record, verification of mapper Id details with source system before making active, etc.,

Happy to connect with the teams interested to discuss further on a call and on this discussion thread to hash out additional assumptions for scope in first phase.

[pramodkvarma]

Important use case which has some nice global demand. A reference solution built on RC would be appropriate.

[tejash-jl]

Closing this discussion, as it will be tracked here
https://github.com/orgs/G2P-Connect/discussions/23