GITBOOK-15: change request with no subject merged in GitBook

G2P-Connect · Jul 27, 2023 · 026bc2b · 026bc2b
1 parent 38639af
commit 026bc2b
Show file tree

Hide file tree

Showing 8 changed files with 28 additions and 33 deletions.
diff --git a/docs/README.md b/docs/README.md
@@ -1,4 +1,4 @@
-# 🥇 Overview
+# 🔍 Overview
 
 In its daily workings, governments across local, state and national levels make various payments to people of a country. This may be in the form of subsidies, pensions, scholarships, incentives during emergencies and more. Citizens may choose to receive these payments in different ways such as through cash, bank transfers, mobile wallets, prepaid vouchers, etc.&#x20;
 

diff --git a/docs/SUMMARY.md b/docs/SUMMARY.md
@@ -14,9 +14,9 @@
   * [📃 Credentialing](protocol/interfaces/credentialing.md)
   * [® ® Registries](protocol/interfaces/registries.md)
   * [🧏 Beneficiary Management](protocol/interfaces/beneficiary-management/README.md)
-    * [🗂 Mapper Architecture](protocol/interfaces/beneficiary-management/mapper-architecture/README.md)
-      * [🔗 Mapper Specs](protocol/interfaces/beneficiary-management/mapper-architecture/mapper-specs.md)
-    * [Eligibility Checks](protocol/interfaces/beneficiary-management/eligibility-checks.md)
+    * [Mapper Architecture](protocol/interfaces/beneficiary-management/mapper-architecture.md)
+    * [Mapper Specs](protocol/interfaces/beneficiary-management/mapper-specs.md)
+    * [Eligibility Determination](protocol/interfaces/beneficiary-management/eligibility-checks.md)
   * [⚙ Social Program Management](protocol/interfaces/social-program-management/README.md)
     * [💲 Dibursement](protocol/interfaces/social-program-management/disbursement.md)
 * [🔐 Security](protocol/security/README.md)

diff --git a/docs/g2p-connect/solution-blueprint.md b/docs/g2p-connect/solution-blueprint.md
@@ -7,7 +7,7 @@
 1. Foundational Digital ID System
 2. Trusted Data Sharing & Digital Credentialing Infrastructure
 3. Civil & Other Federated Registries
-4. [ID-Account Mapper](../protocol/interfaces/beneficiary-management/mapper-architecture/)
+4. [ID-Account Mapper](../protocol/interfaces/beneficiary-management/mapper-architecture.md)
 5. Social Program & Beneficiary Management
 6. Payment & Settlement Switch
 7. Bank/Mobile-wallet System

diff --git a/docs/protocol/interfaces/README.md b/docs/protocol/interfaces/README.md
@@ -4,15 +4,15 @@
 
 Below core interfaces & codes help to easily identity functional areas for implementation partners.
 
-| Interface (Code)                                                                             | Version                                                               | Release Date | Description                                      |
-| -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | ------------ | ------------------------------------------------ |
-| [Identity](identity.md) (ID)                                                                 | [0.1.0](https://g2p-connect.github.io/specs/dist/g2p-identity.html)   | Draft        | APIs to access authentication & eKYC services    |
-| [Credentialing](credentialing.md) (CRED)                                                     | [0.1.0](https://g2p-connect.github.io/specs/dist/g2p-credential.html) | Draft        | Issue, manage digital verifiable credentials     |
-| [Registries](registries.md) (REG)                                                            | [0.1.0](https://g2p-connect.github.io/specs/dist/g2p-crvs.html)       | Draft        | Subscribe, Notify and Search civil registry info |
-| [Financial Address Mapper](beneficiary-management/mapper-architecture/mapper-specs.md) (FAM) | [0.1.0](https://g2p-connect.github.io/specs/dist/g2p-mapper.html)     | Draft        | Manage ID to financial address mapper registry   |
-| [Disbursement](social-program-management/disbursement.md) (DSBT)                             | [0.1.0](https://g2p-connect.github.io/specs/dist/g2p-disburse.html)   | Draft        | Payment disbursements                            |
-| Social Program Management (SPM)                                                              | 0.1.0                                                                 | Draft        | Manage social programs                           |
-| Beneficiary Management (BM)                                                                  | 0.1.0                                                                 | Draft        | Manage beneficiaries                             |
+| Interface (Code)                                                         | Version                                                               | Release Date | Description                                      |
+| ------------------------------------------------------------------------ | --------------------------------------------------------------------- | ------------ | ------------------------------------------------ |
+| [Identity](identity.md) (ID)                                             | [0.1.0](https://g2p-connect.github.io/specs/dist/g2p-identity.html)   | Draft        | APIs to access authentication & eKYC services    |
+| [Credentialing](credentialing.md) (CRED)                                 | [0.1.0](https://g2p-connect.github.io/specs/dist/g2p-credential.html) | Draft        | Issue, manage digital verifiable credentials     |
+| [Registries](registries.md) (REG)                                        | [0.1.0](https://g2p-connect.github.io/specs/dist/g2p-crvs.html)       | Draft        | Subscribe, Notify and Search civil registry info |
+| [Financial Address Mapper](beneficiary-management/mapper-specs.md) (FAM) | [0.1.0](https://g2p-connect.github.io/specs/dist/g2p-mapper.html)     | Draft        | Manage ID to financial address mapper registry   |
+| [Disbursement](social-program-management/disbursement.md) (DSBT)         | [0.1.0](https://g2p-connect.github.io/specs/dist/g2p-disburse.html)   | Draft        | Payment disbursements                            |
+| Social Program Management (SPM)                                          | 0.1.0                                                                 | Draft        | Manage social programs                           |
+| Beneficiary Management (BM)                                              | 0.1.0                                                                 | Draft        | Manage beneficiaries                             |
 
 ### Other Interfaces
 

diff --git a/docs/protocol/interfaces/beneficiary-management/eligibility-checks.md b/docs/protocol/interfaces/beneficiary-management/eligibility-checks.md
@@ -1,17 +1,17 @@
-# Eligibility Checks
+# Eligibility Determination
 
-COVID accelerated the use of the digital payments infrastructure by the various national and sub national governments to enable the Direct Benefit Transfers. While this helped provide support for millions across the world, a new challenge is emerging which requires due attention. In order to make direct transfers governments need to identify the beneficiaries for the various schemes - based on the scheme specific criteria. The data required for determining eligibility may include land holdings, electricity usage, vehicle ownership, financial transactions, age, gender, caste etc. These records currently reside in the respective departments but many ministries/departments are running initiatives to pull data into a centralised database.&#x20;
+In order to make direct transfers governments need to identify the right beneficiaries for the various schemes - based on the scheme specific criteria. The data required for determining eligibility may include land holdings, electricity usage, vehicle ownership, financial transactions, age, gender, caste etc. These records currently reside in the respective departments but many ministries/departments are running initiatives to pull data into a centralised database.&#x20;
 
-Over time systems have collates all the data into a centralised databases are in a position to correlate these data to formulate a comprehensive profile of all the citizens. While the objective of such databases is to identify eligible beneficiaries, there are several challenges in these initiatives that need to be thought through.
+Over time systems have collated all the data into a centralised databases and are in a position to correlate these data to formulate a comprehensive profile of all the citizens. While the objective of such databases is to identify eligible beneficiaries, there are several challenges that may not aling with an ideal DPI design principles.
 
 1. **Single Source of Truth** - The respective departments are the legal “registrars” of the respective attributes e.g. Vehicle records are owned by the Road Transport Department and so on. If data is being pushed into the central database, the ownership of ensuring the data is up to date should reside with the respective departments. The system must be designed in a manner to ensure that the most recent record is used to determine the eligibility criteria.
 2. **Security** - Creating such a centralised database will make it a high risk asset and will require substantial investments in security to ensure adequate protection. Any compromise and unauthorised access to this database may cause irreverasable damage.&#x20;
 3. **Privacy** - Several questions around privacy arise which needs to be addressed e.g. will beneficiaries have visibility in the attributes that are being stored and used for eligibility determination, is there a process for them to raise correction requests, what mechanisms are put in place to ensure limit purpose of use of these databases, can beneficiaries opt out of such a database, etc.
 4. **Anomaly Detection** - Since this database will be used for beneficiary eligibility, it will be a target for fraud. Mechanisms need to be put in place to detect anomalies e.g. population stability indexes must be computed and compared to ensure no large scale changes in the database are happening to enable inclusion in a specific scheme.
 
-To address the above concerns, designers of these systems must consider federated services architecture rather than centralised databases. Instead of pulling all the data into a central database, it may be possible to implement a centralised “Beneficiary Eligibility” service which in turn calls respective departments “Beneficiary Eligibility” service that returns a “Yes/No” answer or minimal required information. So a scheme system queries the centralised beneficiary eligibility API by sending one or multiple records to it. The service then calls the respective department systems to check the beneficiary eligibility in their respective databases and revert with a result.
+To solve for above design principles, designers of these systems must consider federated services architecture rather than centralised databases. Instead of pulling all the data into a central database, it may be possible to implement a centralised “Beneficiary Eligibility” service which in turn calls respective departments “Beneficiary Eligibility” service that returns a “Yes/No” answer or minimal required information. So a scheme system queries the centralised beneficiary eligibility API by sending one or multiple records to it. The service then calls the respective department systems to check the beneficiary eligibility in their respective databases and revert with a result.
 
-The social program registry may cache this minimal information and additionally integrate with subscribe/notify api's to get notified on any source data changes at an agreed frequency to ensure latest correct data is available.
+The social program registry may **cache** this minimal information and additionally integrate with subscribe/notify api's to get notified on any source data changes at an agreed frequency to ensure latest correct data is available. This API driven approach shall ensure seamless integration with no manual intervention for each refresh cycle. &#x20;
 
 Registration into social program scheme can allow beneficiary **grant/revoke consent** to access federated registries. Social program eligibility rules determine the source data sources to be linked to enable eligibiltiy determination. In addition to beneficiary consent, additional governance policies between systems to control attribute, aggregate level access to bring in trust.
 

diff --git a/...-management/mapper-architecture/README.md → ...ficiary-management/mapper-architecture.md b/...-management/mapper-architecture/README.md → ...ficiary-management/mapper-architecture.md
@@ -1,4 +1,4 @@
-# 🗂 Mapper Architecture
+# Mapper Architecture
 
 ## Technology Architecture
 
@@ -19,7 +19,7 @@ The G2P Connect Blueprint, among other functions, enables abstraction of the tar
 
 Designing a Financial Address Mapper (FAM) should meet below core design principles. It is highly recommended that policy & technical architects take below principles into consideration when conceptualising and designing Financial Address Mapper as a Digital Public Infrastructure.
 
-![](../../../../.gitbook/assets/mapper\_principles.png)
+![](../../../.gitbook/assets/mapper\_principles.png)
 
 ### 2.1 Minimalism
 
@@ -105,15 +105,15 @@ Beneficiaries get following benefits:
 1. Manage store of value account info to receive all social benefits with one single entity and manage any life cycle changes only once.
 2. Don’t have to share sensitive financial account information with multiple entities.
 
-![](../../../../.gitbook/assets/mapper\_benefits\_benficiary.png)
+![](../../../.gitbook/assets/mapper\_benefits\_benficiary.png)
 
 ### 3.4 Social Protection System
 
 System delivering social protection to beneficiaries.
 
 Social protection systems enable with following capabilities: Help interface Beneficiary to manage ID to Store of value address with entity hosting the mapper registry. Create disbursement instructions to payment processing systems/rails to initiate benefit transfer using beneficiary id.
 
-![](../../../../.gitbook/assets/mapper\_benefit\_depts.png)
+![](../../../.gitbook/assets/mapper\_benefit\_depts.png)
 
 ## 4. Mapper Features
 
@@ -127,15 +127,15 @@ G2P Connect specifications recommends below features to be available to enable s
 
 Below is an illustration of mapper implemenation to benefit beneficiary to access funds or draw cash:
 
-![](../../../../.gitbook/assets/mapper\_flow.png)
+![](../../../.gitbook/assets/mapper\_flow.png)
 
 ## 5. Recommended Best Practices
 
 1. G2P Connect specification allows more than one mapper registry within a country. Having a registry within each ministry/agency or sector is perfectly fine as part of initial roll out and if there are enough synergies and trust built up, incremental consolidation will help both implementing agencies, beneficiaries.
 2. Entities enabling linking (and life cycle management services) with mapper registry MUST authenticate the Owner of the account holder with the ID of the person being linked is indeed the same person. Specifications allow any existing authentication methods followed by the store of value service provider.
 3. Obtaining consent is decentralised with the entities operating in the mapper registry ecosystem. This enables existing systems and business processes to adopt mapper registry as Digital Public Infrastructure. Migrating to Digital Consents shall help in population scale with trust and enable automation.
 
-![](../../../../.gitbook/assets/mapper\_hosting\_options.png)
+![](../../../.gitbook/assets/mapper\_hosting\_options.png)
 
 ## 6. Next Steps
 
@@ -144,10 +144,6 @@ Countries may use the below checklist to start the DPI journey:
 1. The Ministry/Department operating one or more social benefit program(s) may consider a single Mapper Registry as Digital Public Infrastructure building block Department to identify. This agency may own and operate the Mapper registry.
 2. Work with ecosystem participants to identify policies and operational guidelines to use the existing services digitally.
 
-
-
-
-
 ## 7. Additional References
 
 1. Financial Address Mapper - [Architecture Overview](https://docs.google.com/presentation/d/e/2PACX-1vRm6L3Bn2wvOA39-E78Y8K3vUPVy\_eH9IqAQkk9teNEKqxbM-fslXoh2scf5-\_MXLTWpkqg1R17ejd0/pub?start=false\&loop=false\&delayms=3000)

diff --git a/...ement/mapper-architecture/mapper-specs.md → ...es/beneficiary-management/mapper-specs.md b/...ement/mapper-architecture/mapper-specs.md → ...es/beneficiary-management/mapper-specs.md
@@ -1,4 +1,4 @@
-# 🔗 Mapper Specs
+# Mapper Specs
 
 ### Assumptions
 
@@ -27,5 +27,4 @@
 
 ### Integration Schematics
 
-<figure><img src="../../../../.gitbook/assets/interface-mapper.drawio.png" alt=""><figcaption></figcaption></figure>
-
+<figure><img src="../../../.gitbook/assets/interface-mapper.drawio.png" alt=""><figcaption></figcaption></figure>
diff --git a/docs/protocol/overview.md b/docs/protocol/overview.md
@@ -1,4 +1,4 @@
-# Overview
+# 🔍 Overview
 
 G2P Connect API Specifications is an open source effort to standardise the key integrations across functional categories defined in G2P Connect Technology Architecture [Blueprint](../g2p-connect/solution-blueprint.md).