TSocial Protection Interoperability Standard

Business-Level Specification – Information Flows Between Layers

Version: 1.0.002 Draft
Date: 26 June 2026
Status: Working Draft for Review
Purpose: Define the key information flows that allow functional layers to work together in social protection delivery.

How to Read This Document

This standard describes functional layers and the information that needs to move between them.

The layers are:

• Social Registry (SR)

• Beneficiary Operations Management (BOMS)

• Integrated Beneficiary Registry (IBR)

These are not necessarily separate systems. One software platform or organization may implement one layer, two layers, or all three. What matters is that when information crosses from one layer to another, it follows agreed patterns so that programs can coordinate.

The focus is on business flows — what information moves, why it moves, and in which direction. Internal rules, calculations, or technical implementation details inside each layer are out of scope.

1. The Three Functional Layers

Social Registry (SR)

Business purpose: Understand who may need support and why.

• Maintains a broad view of individuals and households and their circumstances.

• Supports registration and updates from people (on demand or through outreach).

• Incorporates data from other sources to assess needs and conditions.

• Provides information that programs can use to identify potential beneficiaries.

• Enables dynamic response — new people can be added or information updated when situations change (including during shocks).

This layer focuses on potential need and eligibility signals.

Beneficiary Operations Management (BOMS)

Business purpose: Run the day-to-day operations of one or more specific programs.

• Receives information about potential beneficiaries.

• Applies program-specific rules to decide enrolment.

• Determines the benefits or services a person or household should receive.

• Manages delivery of those benefits (cash, in-kind, services).

• Tracks relevant events during the program (conditions met, grievances, updates).

• Records what was actually delivered for its own program.

This layer focuses on operational delivery for a defined program.

Integrated Beneficiary Registry (IBR)

Business purpose: Provide a consolidated view of what support has actually been delivered across programs.

• Receives records of benefits and services that have been delivered (after programs have executed and reconciled them).

• Allows visibility across programs: who has received what, when, and from which program.

• Supports coordination by highlighting overlaps, gaps, or opportunities for complementary support.

• Enables transparency for beneficiaries and authorized users (a consolidated picture of support received).

• Provides inputs for analysis of overall coverage and performance.

This layer focuses on actual delivered support (the "supply" side).

Key distinction at business level:

• SR answers "Who might need help?"

• BOMS answers "How do we deliver this specific program to those who qualify?"

• IBR answers "What support has actually been provided across programs, and to whom?"

2. Core Information Flows

These flows are the heart of the interoperability standard. They describe the main ways information should move so that the layers can reinforce each other.

Evaluation: Rapid Size and Count Assessment (Direct Output Path)

Between: BOMS and SR

Business reason: Programs and planners frequently need a fast sense of scale — for example, "How many people in this district might meet the criteria for this shock-response program?" or "What is the estimated coverage gap?" — to support quick resource planning and decision-making. This must happen without exposing any individual private information.

What is exchanged (business view): Aggregate counts, optional disaggregation (e.g., by geography, age group, or vulnerability category), and statistical extrapolation where appropriate. Privacy safeguards apply, such as suppressing results for very small counts.

When it typically happens: During program design, shock response planning, budget estimation, or rapid assessment. This path is designed for speed and low risk.
Key interoperability elements: see Enrolment Data

Outcome: Programs receive immediate, usable estimates for planning while the privacy of individuals is fully protected. No personal data leaves the layer.

Enrolment Data: Detailed Listing (Vetted Access Path)

Between: SR and BOMS

Business reason: When a program needs to move from planning to actual action (contacting or enrolling specific people), it requires the detailed list. However, releasing individual data carries privacy risks and must only occur under proper authorization.

What is exchanged (business view): A request token or reference is issued first. After authorization and any required vetting, the approved list is provided (with only the fields needed for the authorized purpose). the data is composed of the preson, groups, assets folowing as extensible standrad representation

When it typically happens: After a program has used size/count information to decide on scale and now needs to operationalize delivery or enrolment. Could also applies during the life of the program to update the information, enroll or graduate person as their situation evolves

Key interoperability elements: the criteria should follow as strucutured and machine readable format that could be tested on the person or group including their assets, residences, enrolment, benefits and the relates attributes, the data should be standardised both for their format and on the semantics demarcation for the asstribute of the person/group/asset/residence/payment types (data disctionnary should be shared)

Outcome: Individual-level information is shared only with properly authorized parties, maintaining a strong privacy wall while still enabling effective program implementation.

Benefits and Enrolment: Actual Delivery Records to Cross-Program View

Between: BOMS and IBR/SR

IBR Business reason: To build an accurate picture of what support has actually reached people, programs must share the results of their delivery (not just plans).
SR Business reason: Knowing what support people have already received helps avoid duplication and improves future targeting and needs assessment.

What is exchanged (business view): Records showing that specific benefits or services were delivered to specific people (after any reconciliation with the actual payment or distribution channel). This includes timing and nature of the support.

When it typically happens: After delivery cycles or when status changes for a beneficiary (e.g., new enrolment completed, payment made, service provided).

Key interoperability elements: See Program data sections

Outcome: IBR holds a reliable record of actual support provided across programs.

Notifications: Share information about updates

Between: Any layer (SR, BOMS, IBR) to other layers or to beneficiaries/programs

Business reason: Timely awareness of new opportunities, shocks, status changes, or required actions.

What is exchanged (business view): Notifications about new or updated support options, shock responses, delivery confirmations, or important changes.

Key interoperability elements: the notifications should be minimal, if the recipent is interest it should get the related resource using the reference persent in the notification: several technology are possible depending on the local capacities.

Outcome: Faster, more coordinated action across the system.

Program Data: Sharing details and opportunities

Between: BOMS and IBR/Beneficiary App

Business reason: Enable getting details of the notified updates or proactivily get information on available or enrolled program, and program events,

What is exchanged (business view): Notifications about new or updated support options, shock responses, delivery confirmations, or important changes.

Key interoperability elements: should used a standard model that allows the reciepent to be able to process them without code changes, the data should be standardised both for its format and on the semantics demarcation for the attributes of the BenefitPlan, Enrolments, events, Benefits (data disctionnary should be shared)

Outcome: Data Synchonisation is possible between systems.

Data-in: External Data into Assessment

between: Authoritative data sources and IBR

Business reason: Enrich the picture of needs with verified information without burdening people with repeated requests.

What is exchanged (business view): Relevant verified attributes or assests (with clear provenance and under appropriate authorization) using a standardized format. the SR should map those infromation toward resource such as Person, Group, assets, residence,payment methods

Outcome: More accurate and up-to-date information in the assessment layer.

3. Principles for These Flows

• Information should move only when there is a clear business purpose.

• Privacy and authorization are respected at every exchange — layers only receive what they are entitled to see.

• The standard distinguishes between potential (assessment) and actual (delivered) information.

• Flows should support both routine operations and rapid response to shocks.

• One system may implement multiple layers; the flows still apply at the boundaries between layers.

• The goal is coordination and transparency, not central control of every decision.

• A key privacy mechanism is the separation between direct size/count outputs (for fast, low-risk assessment) and vetted detailed lists (for operational use). This allows programs to get quick scale estimates without exposing personal data.

Data objects by master system

• Foundation: Data types, identifiers, external standards.

• Core: Locations, Organisation.

• Authoritative data sources: documents

• SR: Person, Group, Assets, Residence, Payment Methods, Documents.

• BOMS: BenefitPlan, Enrolments, events, benefits

• IBR being an integration layer, is not a master of any data object

4. Example End-to-End Business Scenarios

Shock Response

1. A shock occurs.

2. BOMS define its actions using the SR sizing to ensure its effectivness

3. BOMS enrol using the SR targeting to enrol, provide benefits and later shares what was actually delivered.

4. IBR updates the consolidated view and can feed coverage signals back to the Social Registry.

5. Beneficiaries receive notifications and can see their support via the consolidated view.

Routine Cross-Program Coordination

1. Several programs (each with their own BOMS) deliver support that may overlap.

2. Each BOMS shares reconciled delivery records with IBR

3. IBR makes visible overlaps, gaps, or complementarities.

4. Authorized users query or receive notifications from IBR.

5. IBR provides feedback to SR where it can improve future assessment.

These scenarios illustrate how the flows connect the layers to achieve better outcomes.

5. Benefits of Defining Flows at This Level

• Business experts can validate whether the right information is moving for the right reasons.

• Different programs and systems can participate without having to agree on every internal detail.

• Clear flows reduce duplication of data collection from citizens.

• Implementers retain flexibility on how they combine or separate the layers inside their own systems.

6. What Is In Scope and Out of Scope

In scope for this business-level standard:

• Description of the functional layers and their main business purposes.

• Definition of the key information flows between layers (direction, purpose, high-level content).

• High-level expectations for privacy and authorization around the flows.

Out of scope (technical details to be addressed later):

• Exact data structures or message formats.

• Specific technical protocols or APIs.

• Internal rules or algorithms inside any layer.

• How a particular software product should implement one or more layers.

• Full legal or security architectures (assumed to exist around these flows).