You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/README.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# 🥇 Overview
1
+
# 🔍 Overview
2
2
3
3
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. 
Copy file name to clipboardExpand all lines: docs/protocol/interfaces/beneficiary-management/eligibility-checks.md
+5-5Lines changed: 5 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,17 +1,17 @@
1
-
# Eligibility Checks
1
+
# Eligibility Determination
2
2
3
-
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. 
3
+
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. 
4
4
5
-
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.
5
+
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.
6
6
7
7
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.
8
8
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. 
9
9
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.
10
10
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.
11
11
12
-
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.
12
+
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.
13
13
14
-
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.
14
+
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.  
15
15
16
16
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.
Copy file name to clipboardExpand all lines: docs/protocol/interfaces/beneficiary-management/mapper-architecture.md
+6-10Lines changed: 6 additions & 10 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# 🗂 Mapper Architecture
1
+
# Mapper Architecture
2
2
3
3
## Technology Architecture
4
4
@@ -19,7 +19,7 @@ The G2P Connect Blueprint, among other functions, enables abstraction of the tar
19
19
20
20
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.
System delivering social protection to beneficiaries.
113
113
114
114
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.
@@ -127,15 +127,15 @@ G2P Connect specifications recommends below features to be available to enable s
127
127
128
128
Below is an illustration of mapper implemenation to benefit beneficiary to access funds or draw cash:
129
129
130
-
130
+
131
131
132
132
## 5. Recommended Best Practices
133
133
134
134
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.
135
135
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.
136
136
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.
@@ -144,10 +144,6 @@ Countries may use the below checklist to start the DPI journey:
144
144
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.
145
145
2. Work with ecosystem participants to identify policies and operational guidelines to use the existing services digitally.
Copy file name to clipboardExpand all lines: docs/protocol/overview.md
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# Overview
1
+
# 🔍 Overview
2
2
3
3
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).
0 commit comments