Seen Without Being Watched: The Privacy Boundary MBG Needs for Beneficiary Validation

MBG Watch · 2026-08-14

The accountability problem

MBG’s beneficiary number is not an administrative detail. It is the denominator behind the budget, the kitchen map, food purchasing, route planning, corruption detection, and any claim that the program is improving nutrition.

BGN’s own public record shows the scale of the issue. In a 20 January 2026 press release, BGN said MBG had reached about 59.86 million beneficiaries through 21,102 SPPG units, with almost Rp18 trillion already disbursed and a projected 82.9 million beneficiaries by mid-year. MBG Watch’s earlier piece, “BGN Asks the Question It Should Have Asked First: Is 63 Million Beneficiaries Real?”, treated that denominator as the program’s first integrity test. The point was not to dispute a single figure for its own sake. It was to ask whether the meal count is anchored in people who actually exist, are eligible, are served, and can be corrected when the record is wrong.

That question now sits beside MBG Watch’s other visibility work: “Inspectable by Design” argued that validation and grading must be inspectable rather than score-only; “The Visibility Standard” argued that canteen or kitchen pivots should not scale without public control records; “The Route Is Part of the Kitchen” argued that dispatch after the kitchen door must be visible; and “Why MBG Has No Measurable Nutrition Outcomes — The Corruption-Nutrition Pathway” warned that captured data and social-media management can make a program look better while children remain unprotected.

The missing boundary is privacy. MBG needs a validation record strong enough to expose ghost recipients, duplicate counts, missed meals, unexplained discard, and route leakage. But a child-nutrition program should not become a child-surveillance system.

The privacy problem

Indonesia’s Personal Data Protection Law, Law No. 27 of 2022, gives BGN a useful starting point. The law treats children’s data as “Specific Personal Data,” alongside health information and biometric data. It also requires processing to be limited, specific, legally valid, transparent, purpose-aligned, accurate, accountable, and protected against unauthorized access, disclosure, alteration, misuse, destruction, or loss. Article 25 says children’s personal data must be processed in a special manner and requires consent from parents and/or guardians in accordance with law.

That framework matters because MBG’s operational record could easily combine several high-risk categories: child identity, school attendance, health or nutrition status, disability status, household vulnerability, location, and perhaps future digital identifiers such as QR codes, parent apps, or biometrics. Even when each field appears harmless alone, combinations can identify a child or household indirectly.

The global governance lesson is similar. UNICEF and The GovLab’s Responsible Data for Children initiative frames children’s data around prevention of harms across the data life cycle, proportionality, purpose, accountability, and children’s rights. The World Bank Group’s personal-data policy defines personal data broadly as information relating to an identified or identifiable individual, including identification numbers, location data, metadata, and combinations of attributes. It also states the familiar discipline MBG needs here: collect personal data for specific legitimate purposes; keep the amount and type necessary and proportionate; retain identifiable data only as long as needed; and protect it with organizational and technical safeguards.

The lesson is not that MBG should avoid data. It is that MBG should separate three different records that are often blurred together.

A three-layer record

MBG needs one public record, one controlled audit record, and one protected personal record. Each layer should answer a different accountability question.

The public record should answer: did this school, kitchen, and route deliver the number of meals they claimed, safely and on time? It should not identify children.

The controlled audit record should answer: can an authorized inspector verify that the aggregate record is real, that there are no duplicate or ghost recipients, and that corrections were handled properly? It may need named or pseudonymized child-level data, but only under access controls, logging, retention limits, and sanction for misuse.

The protected personal record should answer: what does this child or household need for service delivery, correction, opt-out, or safeguarding? This is the narrowest layer. It should not be public, searchable by broad program staff, or reused for unrelated education, policing, political, commercial, or social-media purposes.

This structure is not unusual. Large school-meal systems already distinguish eligibility verification from public disclosure. The U.S. Food and Nutrition Administration, for example, maintains specific disclosure requirements for child nutrition programs around student eligibility information. MBG does not need to copy U.S. law. But the distinction is useful: verification can exist without publishing the child-level eligibility file.

What should be public

The public MBG validation record should be operational, not personal. At minimum, BGN should publish machine-readable records at school, kitchen, route, district, and time-period level. The public does not need a child’s name to know whether a kitchen’s claim is plausible.

For each school or beneficiary institution, public fields can include:

• institution name and official code;
• district, subdistrict, and province;
• beneficiary category totals, such as primary students, secondary students, pregnant women, breastfeeding mothers, toddlers, or other approved categories, without names;
• registered beneficiary count for the period;
• daily meals ordered, prepared, delivered, served, missed, returned, discarded, and replaced;
• reasons for non-service or discard, using controlled categories;
• kitchen/SPPG identifier serving the institution;
• route identifier and scheduled dispatch/arrival windows;
• actual dispatch and receipt timestamps, rounded enough to verify service without exposing child movement;
• menu code, batch code, halal and food-safety control status, and water/cold-chain readiness where relevant;
• correction counts: additions, removals, duplicates resolved, eligibility changes, opt-outs, and complaints resolved;
• audit status: not audited, desk-checked, field-checked, exception found, exception closed.

For each SPPG or kitchen, public fields can include:

• kitchen identifier, operator type, district, and service radius;
• active beneficiary institutions served;
• daily production capacity and actual meals prepared;
• procurement totals by broad ingredient category;
• batch logs and hold-time compliance;
• dispatch routes and route completion status;
• sanitation, water, energy, and accreditation status;
• suspension, warning, or corrective-action status.

For each route, public fields can include:

• route identifier;
• serving kitchen and destination institution codes;
• planned and actual departure/arrival time windows;
• meals loaded, meals received, meals rejected, meals returned;
• vehicle/handler compliance status without naming low-level workers unless a formal sanction is already public;
• exception reason and corrective action.

These fields would make ghost-recipient leakage harder. A school with 800 enrolled students but a recurring 1,050 meal claim would stand out. A kitchen that prepares more meals than its assigned beneficiary institutions can absorb would stand out. A route that repeatedly records high discard or missing receipts would stand out. None of that requires a child’s public identity.

What auditors may inspect

Auditors need more than the public record. They need to test whether the denominator is real.

Under controlled access, auditors may need to inspect:

• named beneficiary rosters held by schools or authorized service points;
• enrollment or eligibility source documents;
• parent or guardian consent records where personal data processing requires them;
• hashed or pseudonymized unique identifiers used to detect duplicates across schools, kitchens, and districts;
• exception files for transfers, absences, opt-outs, allergies, medical restrictions, or special diets;
• correction trails showing who changed a record, when, why, and under what authority;
• complaint records and resolution evidence;
• samples connecting meal receipt, attendance, and service delivery, where legally permitted and necessary.

Even here, access should be role-based and logged. Auditors should see the data needed to answer a specific integrity question, not a live national child dossier. The controlled record should support sampling and exception testing. It should not become a general-purpose dashboard for browsing children.

A practical compromise is to use pseudonymous IDs for routine audit matching, with re-identification permitted only for authorized school officials, parents or guardians seeking correction, and auditors working under a defined mandate. Duplicate detection does not require every kitchen operator to know every child’s civil identity.

What should remain protected

Several fields should not be public and should not be visible to routine operators unless directly necessary for service delivery:

• child name and household member names;
• national ID or family-card numbers;
• biometric identifiers, including face, fingerprint, or iris templates;
• precise child-level attendance, location, or route history;
• individual health, nutrition, disability, allergy, pregnancy, or breastfeeding records;
• household poverty status or social-assistance category when it can stigmatize a child;
• family phone numbers and addresses;
• parent-app usage data or message logs;
• complaint narratives that identify a child, family, whistleblower, teacher, or kitchen worker;
• photos or videos of identifiable children used as evidence without strict safeguarding.

The protected layer should also have deletion and retention rules. MBG may need a meal-service record for reconciliation, audit, and dispute resolution. It does not need permanent, broadly accessible child-level movement and consumption histories.

Red flags MBG Watch will monitor

If BGN digitizes beneficiary validation or kitchen transparency, MBG Watch will watch for several warning signs.

First, biometric creep. Biometrics may look like a clean anti-fraud tool, but under Indonesia’s PDP framework biometric data and children’s data are both sensitive. A national meal program should not normalize face or fingerprint checks for children unless BGN can show a strict necessity test, a less intrusive alternative analysis, parental/guardian consent where required, independent security assessment, breach response capacity, and a non-punitive fallback for children who cannot or should not use the system.

Second, coercive consent. Consent is weak if refusal means a child loses a meal, a parent is treated as suspicious, or a school is punished for protecting families. Where processing is mandatory for a public service, BGN should be transparent about the legal basis and safeguards rather than dressing compulsion as consent.

Third, exclusion by false precision. A digital match can be wrong. Names can be misspelled. Children move schools. Household records lag reality. Connectivity fails. If the system treats a mismatch as proof of ineligibility, the anti-fraud layer can become a hunger layer. The correction path must be visible, quick, and available offline.

Fourth, surveillance creep. Data collected to validate a meal should not be reused to rank families, police absences, target political communication, build commercial profiles, or generate publicity content. Purpose limitation has to be written into system design, contracts, staff permissions, and audit logs.

Fifth, contractor opacity. If vendors build dashboards, QR systems, parent apps, route tools, or data warehouses, BGN should publish the data-processing roles, retention rules, subcontractors, breach duties, and audit rights. Accountability cannot stop at the ministry door.

Sixth, public dashboards that are too personal. A dashboard that exposes a child, a family’s vulnerability, or a daily attendance pattern is not transparency. It is leakage with a civic label.

The least-harm standard

The least-harm position is simple: MBG should be publicly verifiable at the operational layer, strongly auditable at the integrity layer, and private at the child layer.

That means BGN can publish enough to let citizens, journalists, schools, local governments, and parliament test whether meals were budgeted, prepared, dispatched, received, served, missed, or wasted. It can give auditors enough controlled access to find duplicate and ghost recipients. It can let parents and guardians correct records. And it can do all of that without publishing children’s names, biometrics, health data, family vulnerabilities, or movement histories.

This is not an argument against technology. It is an argument for restraint in the right place. A child-nutrition program should be seen clearly by the public. The child should not have to be watched in order for that to happen.

What remains uncertain

MBG Watch has not seen a full public beneficiary-validation architecture from BGN: the fields collected, the identifiers used, the access roles, the retention periods, the correction process, the vendor contracts, or the safeguards for children’s data. If those documents exist, they should be published in a form that allows scrutiny without exposing personal data.

It is also not yet clear how BGN will reconcile school enrollment records, special beneficiary categories, daily attendance, route receipts, and meal counts across districts. That uncertainty is precisely why the privacy boundary should be set before the validation system hardens. Once a national child-level data system is built, later restraint becomes harder.