G2P Solution Blueprint - Finance System?

[eGovMan]

Thanks @vvujjini for the invite. Very excited to be part of the G2P community.

This is my first post here. I am CTO with eGov Foundation. You can find our work at (https://egov.org.in).

I was looking at the G2P Solution Blueprint (https://g2p-connect.gitbook.io/docs/g2p-connect-protocol/blueprint). I am presuming that all the lines between the boxes are being detailed out as the G2P Specification. Is that a correct understanding? How should I interpret the dotted lines and the fixed lines?

I had some early observations regarding finance system. Maybe this has been discussed before but I could not find any search result on this hence starting a new discussion.

As per my understanding (limited to some Indian states), all implementing agencies have to raise a Payment Request to a Finance Department/Ministry which then goes through an internal approval process then to the Treasury before Payment Advice (or Disbursement Request) is sent to the Bank (or Payment Settlement Switch). This is true for infrastructure, services or benefits use cases. Typically a Scheme Management System interfaces with Finance System which then interfaces with a Payment Switch to a Bank. Not seen any case where benefit payments can be made without first going through a finance system? How does this work in other countries?

We are currently building an open source solution for state government in India to enable an urban livelihood benefit program. I am sharing below typically how the flow and interactions between different actors looks like when the finance system is involved...

1. After programs are announced, typically during the budget, the Program/Scheme information is configured in the finance system. This includes program description, eligibility criteria, limits etc. (But scheme execution may require sub limits e.g. for a specific city, region etc. which may or may not be maintained in the program system. Often scheme systems end up maintaining these granular sub limits.)
2. Corresponding account heads are created in the accounting system. Bank accounts and reconciliation processes are configured to keep data in synch between the accounting and banking system. Then funds are allocated to the account heads for spending.
3. Executing departments or implementing agencies raise high level estimates to check if money is available. Sometimes there are multiple funding agencies involved with money may or may not be transferred to the executing agencies account or transferred in tranches. All funding agencies are interested in getting proof of execution to release the next tranche (but more often than not they never get this data leading to delayed tranche etc.)
4. Then a detailed plan is submitted which may go through several approvals within the implementing agency and then submitted to finance for financial approval. This is also called the detailed plan report.
5. After the plan approval, the funds are blocked - based on fund availability. The execution starts based on the program cycle. For benefit programs, execution involves onboarding contractors/vendors/community groups who may then onboard their own contract workers or field agents etc., beneficiaries identification/enrolment, eligibility verification and then raising a bill with beneficiary details to the finance system. In most cases, this is manually uploaded by the DDO (Disbursement and Drawing Officer) into the IFMS. During enrolment of the beneficiary, it makes sense to check if the beneficiary bank account is validated by calling the Finance Address Mapper to minimise the payment failure.
6. Eligibility verification often requires integration with multiple systems depending on the program criteria - property, attendance, other scheme systems etc. This is a major stumbling block for a benefit transfers as most low capacity environments don't have the adequate data to check eligibility which is why involvement of local community and social audits are being used to check benefits are going to the right people. When data is available, often data is pulled into a single centralised database creating 360 degree citizen database which is also quite problematic for obvious reasons.
7. The bill (including beneficiary details) then goes through an internal approval process of the finance (or funding agency) after which the instructions are sent to the bank.
8. There is a daily reconciliation process with the bank and treasury that reconciles all the payments. It may happen multiple times in a day.
9. Payment information then flows back and forth between the implementing agency (here the scheme system) and the funding agency (finance system) in case of errors and keep the beneficiaries updated.
10. Post payment survey is done to check if the intended beneficiaries got the benefits.

Another question (may be this should be a different thread) as per the solution blueprint the scheme management is a federated i.e. there can exist multiple scheme management systems operating at national, sub-national and local government level or different departments. In such a scenario, getting a unified view for citizens and administrators will require these systems to implement a common API standard for applying, checking eligibility etc. Also they will need to emit standardised data/events and/or provided standardised APIs to pull the well defined information like Program/Scheme Information, Beneficiary, etc. - the basic definitions of common entities and events like Beneficiary_Registered, Benefit_Delivered etc. will be required to enable interoperability between these systems. Any thoughts on that. Are these part of the "Manage Program" and "Manage Beneficiary" Core Interfaces? Has any work started on these?

[vvujjini]

@eGovMan Thanks for calling out the detailed process from IFMIS systems perspective.

I am presuming that all the lines between the boxes are being detailed out as the G2P Specification. Is that a correct understanding? How should I interpret the dotted lines and the fixed lines?

Yes, dotted lines aim is to spec out key interfaces to enable facilitation of end to end requirements to make G2P payment possible. The difference between dotted and fixed lines...Dotted lines are loosely coupled so that any orchestration between building blocks is left to the country implementation while Fixed lines are to ensure external unified interface are exposed to the core building blocks. Internally these core building blocks can facilitate integration to foundational DPI solutions.

I do agree integrating with finance system shall be key. In the current phase of scoping, the focus is on Program/Scheme management platform to address challenges you called out in point no 6. The assumption is, scheme/program conceptualisation has to start with data points to estimate eligible beneficiaries that's privacy protecting and secure. Point #1 and 6 is an iterative process and nothing stops finance system also integrate with underlying building blocks to identity aggregated beneficiary list for planning purposes.

The core principle of G2P Connect with registry/identity/credential/mapper blocks is to move away from centralised data store. In the short to near term based on country/systems maturity we may not achieve this but technically design/specification shall enable to do this!

In an ideal scenario, finance system should look at aggregated data while program/scheme management platforms should deal at individual beneficiary level. G2P Connect doesn't enforce this but as a best practice recommends this differentiation.

I do agree having a finance system as building block and calling out core specifications to meet the integration aspects between Program/Scheme Mgmt, Banking systems with telemetry events should address the flows you have called out. However, I would like to stress internal approval process with in finance systems or any building block for that matter is NOT in scope of G2P Connect.

Any thoughts on that. Are these part of the "Manage Program" and "Manage Beneficiary" Core Interfaces? Has any work started on these?

Your understanding is correct. These are part of G2P Connect scope and work is yet to start.

I do have done some research and my notes are in draft state. I will have these published to spec repo in coming days as a starter. However, I invite you and other community members to actively participate in GitHub specs directly with pull requests. I'm happy to call a 2 or 3 times a week working meeting to facilitate this work.

[eGovMan]

@vvujjini - will be great to work together on defining the specifications for Program and Eligibility bits as well. We are anyway doing a version for a product we are releasing to support a Livelihood Benefits Program like NREGA. Aim here is also to accelerate payments to daily wage workers. Will be good to align. Let me know when you want to connect.

[vvujjini]

@eGovMan i'll reach out 1:1 and schedule a call for today or tomorrow.

In next few days or weeks, I would like all interested teams in Social Protection to come together as a 'Working Group' to contribute and review these spec on program and beneficiary mgmt modules!

[jeremi]

@eGovMan @vvujjini I'm keen to join the discussion as well.