Unified System for Managing Social Goals

|---|---|---|

| project_id / ngo_id | uuid | internal keys USCC |

| external_project_id | string | identifier in grant/agency source |

| name / description | string/text | normalization of titles and subjects |

| theme_code | string | single subject directory (versionable) |

| region_code | string | OKTMO/own code (not specified/required) |

| start_date/end_date | date | for lag calculation and result |

| planned_budget / actual_budget | decimal | "planfact" |

| target_groups | array | (if possible) standardized reference |

Financing

|---|---|---|

| funding_type | enum | grant/subsidy/contract/donation/endowment income |

| amount/currency | decimal/string | store original currency + remittance (if needed) |

| decision_date/payment_date | date | distinguish between solution and actual payment |

| source_system | string | "primary trust key" |

| legal_basis_ref | string | ABO/contract/solution (if available) |

Risks

|---|---|---|

| risk_type_code | enum | risk type (from reference) |

| sovereignty | enum | levels approved by the method |

| evidence_ref | string | link/record identifier in original |

| first_seen/last_seen | date | control relevance |

| disposition | enum | "accepted/in progress/removed" + protocol decision |

Platform architecture, integration patterns and security

Layers of architecture (logical scheme)

Source layer: registries/portals/open data/international statistical services.  

Integration layer: connectors (batch/API), event bus (where permissible), data catalog and data contracts.  

MDM/"SuperRegister" entity matching (match/merge), versioning, line of origin (lineage).  

 Domain showcases "financing", "results", "risks", "geography", "SDGs".  

Service layer: API Gate way, search, reporting, export, notifications.  

UISloy: offices of departments/regions/operator, public showcase (limited set), interface of NGOs.

12 ESUSC functional modules

Source connectors (batch/API; support "not specified" on metadata).  

Office of the source owner (quality control, download statuses).  

MDMcore NPO (deduplication by OGRN/INN, Rules of the "gold card").  

MDM core of projects (normalization of topics, regions, stages).  

Financial tracking (grants/subsidies/contracts; plan fact).  

Outputmodule (project results; import of evaluation showcases/indicators). 

Riskmodule (compliance screening by lists and AML). 

Endowment tour (register of target capital, reporting, income showcase). 

Data catalogue and metadata (data contracts, SLA freshness).  

Analytics and KPI (dashboards "social targets → portfolio →effect").  

Public transparency (depersonalized display cases, open API where permissible).  

Operation and observability (loging, auditing, SRE, DR/BCP).

Integration patterns

BatchETL/ELT for sources without API (or with restrictions), with storage of "raw materials" and repetition of downloads (idempotency).  

APIs for contracts where API officially provided (example: UNdata API; FIAS API; budgetary API). citeturn3search4turn15search5turn5search5  

Event log: Any change in the "gold card" is an event with a version and a base.  

The CDC approach (if there is an interagency bus/internal channels) is like a target state, but in public conditions often "needs clarification".

Safety and compliance GDPR/local requirements

Russian contour (minimum):

- Personal data: the basic law on PD. 

- Localization of PD processing/storage of citizens of the Russian Federation (in terms of clarifying the procedure for processing in networks). 

- Law on Information and Protection of Information. 

- Requirements for PD protection in ISPD (PP No1119). 

- Composition/content of PD protection measures (Order O8 No21). 

- Protection of information in state IP (Order O8 No17).  

- When referring to KII objects - 187FZ (on the safety of KII) and derivative requirements. 

GDPR (international contour):

If the ESPC will process personal data of subjects from the EU/EEA (for example, donors/volunteers/beneficiaries from the EU, or data comes from European partners), the compliance regime GDPR (legal grounds for processing, minimization, rights of subjects, cross-border transfers, etc.) is required. 

Technical measures (checklist): encryption "in transit" and "on disk", separate contours (prod/test), the principle of least privileges (RBAC/ABAC), Invariable audit logs, anomaly detection, key management, mandatory certification / certification for GIS / ISPD requirements (level - "requires clarification" depending on the class / category).

Organizational management model and RACI

Four-level management structure

Strategic level: approval of the target model, the list of social goals / metrics, the rules of publicity, the rules of “endowment-contour”.  

Interagency level of data: harmonization of the list of sources, “data contracts”, quality rules, integration priorities, access policies.  

Platform operator: development/operation, integration, security, user support, release.  

Implementation ecosystem: regions (introduction/verification of regional measures and projects), NGOs (self-renewal of profile, reporting), grant operators/agency (funding and results data).

RACI matrix of key functions (role legend)

Roles:

R1** — "Administration of the President of the Russian Federation" (AP)  

R2** — "Government of the Russian Federation",

R3** — Ministry of Economy (O3)  

R4** —, "Ministry of Digital Development, Communications and Mass Communications of the Russian Federation"

R5* — Ministry of Justice (O2)  

R6** — "Ministry of Finance of the Russian Federation",

"Ministry of Labor and Social Protection of the Russian Federation", 

Ministry of Health of the Russian Federation - Rosstat (O5)  

R10** — Regions of the Russian Federation  

R11** — ESUSC Operator  

R12** — NPO  

Function | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 | R9 | R10 | R11 | R12 |

|---|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|

| Approval of social goals, KPI, Public Policy | A | A | C | C | C | C | C | C | C | I | I | I |

| List of sources and priorities of integration | A | A | R | C | R | C | C | C | C | C | R | I |

| MDMrules "gold card NPO" | I | C | R | C | R | C | C | C | C | C | R | C |

| Reporting/Charter Outline (Ministry of Justice data) | I | C | C | C | A/R | I | I | I | I | C | R | R |

| Funding (grants/subsidies/procurement) | I | C | R | C | C | A/R | C | C | I | C | R | I |

| Riskscreening (AML/lists) | I | C | C | C | R | C | I | I | I | I | R | I |

| Endowmentcontour (regulation + Registry) | A | A | R | C | R | C | C | C | I | C | R | C |

| Operation, safety, compliance | I | C | C | A/R | C | C | I | I | I | I | R | I |

| Communications/Training/Sappport | I | C | C | C | C | C | C | C | I | C | A/R | C |

Note: A/R distribution is specified when selecting a legal operator and financing model.

Road map and budget evaluation

MVP on 90 Days (P0)

Objective MVP: minimum viable “super register” with verification of NGOs and primary funding tracking + Basic Risk Screening.

Connecting 5 sources (P0): 

1) EGRYP (verification, statuses, daily updates). 

2) Departmental register/portal of NGOs (as a basis for identification of NGOs and mandatory reporting/charters). 

3) Register of SONKO (status, which is also associated with the tax logic of donations). 

4) Presidential grants (projects/grants catalogue8search8  

5) List of terrorists and extremists (AMLscreening). 

Minimum functionality MVP:  

Deduplication of NGOs (OGRN/INN) + "Gold Card" v1;  

simple showcase: "NKO → projects → grants";  

flag "SNKO";  

riskflag (AML) + log checks;  

Export/Report to Agencies (CSV/JSON), Data freshness monitoring (SLA by sources).

Deployment phases (1–3)

  title ESUCC launch: MVP → Pilot → Scaling → the Federal Circuit

  dateFormat  YYYY-MM-DD

  section MVP 90 days

  Data design and MDM :a1, 2026-03-05, 30d

  Integration of 5 sources (P0):a2, after a1, 45d

  Showcases + basic risk-screening :a3, after a2, 20d

  section Phase 1 Pilot

  Pilot 3-5 Regions + 10 Departments :b1, 2026-06-01, 120d

  Endowment Contour :b2, after b1, 60d

  section Phase 2 Zooming

  Connecting P1/P2 sources :c1, 2026-11-01, 180d

  Safety certification/strengthening :c2, after c1, 120d

  section Phase 3 Federal launch

  Showcase + KPI contour :d1, 2027-07-01, 180d

Key results by phase: 

Phase 1 (pilot): stable MDM, working out RACI, method KPI, extension of the risk module (ministries of justice). 

Phase 2 (scaling): connection of sources of the budget/procurement circuit and external storefronts, access to the "end-to-end trading" of state money. 

Phase 3 (federal launch): a single federal outline of social target management, public impersonal showcases, regular performance reports.

Budget assessment (indicative)

Important: below are the management benchmarks for assessing the scope of work; the exact amounts depend on the deployment model (public infrastructure / cloud), certification requirements, the volume of integrations and SLA.

MVP (90 days):

CAPEX: 60–150 million rubles (data development / analytics team, basic infrastructure, connectors P0, MDM v1, basic security).  

OPEX (year): 30–80 million rubles (operation, SRE, user support, connector development).

Full run (phases 1–3):

CAPEX: 0,8–2,5 billion Rubles (scaling integrations 20+, industrial safety/certification circuit, showcases and analytics, "endowmentcontour").  

OPEX (year): 15–25% 

CAPEX (operation, security, development, support contracts).

Funding options: 

federal state program/national projects (digitalization), targeted subsidies + co-financing of regions for the pilot, grant mechanisms for individual modules (analytics/openness), partnerships with large donors/businesses for public showcases (requires a separate compliance model).

Regulatory framework, communications, KPI and endoumenttour

Regulatory framework (what is already there and what needs to be prepared)

There are already (support acts):  

- Register of SONCO and powers of reference (PP No1290). citeturn24view0  

- Tax binding of donations to the SONKO register (subpara. 19.6 Art. 265 of the Tax Code of the Russian Federation). 

- Mandatory publication of NGO charters on the resource of the authorized body (order No180; official publication). 

- Electronic reporting of NGOs (Order No. 336; form UN000X; through LC and ESA). 

- The law on target capital (endowments) - basic regulation. 

- IB/PD Perimeter (152FZ, 242FZ, PP 1119, Orders No21/№17, 187FZ) — for the design of ESUC protection. 

GDPR - if the EU/EEA data outline is affected. 

Need to prepare/endorse (package for ESPC launch):

1) Decree of the Government of the Russian Federation on the establishment of the USCC and the approval of the regulation on the "super register" (goals, data composition, access role, interagency interaction).  

2) Approval of the operator of the ESUSC (Federal operator/state agency/GIS operator) and sources of funding.  

3) Regulations of "data contracts" (SLA freshness, responsibility for quality, procedure for corrections).  

4) Regulations on public disclosure of impersonal data and methods of depersonalization.  

5) Separate provision on the public register of endowments (see below).

Government Resolution Template (Skeleton Text)

DECISION OF THE GOVERNMENT OF THE RUSSIAN FEDERATION

"On the creation of a unified system of management of social goals"

1. Create a state information system "Single system of management of social goals" (ESUC).

2. Approve the Regulation on ECSC (Annex No. 1), including:

 2.1. composition and purpose of the data "super register" (NGOs, projects, financing, results, risks);

   2.2. rules of master data management ("gold card of NPO");

   2.3. a list of data sources and access categories;

   2.4. the procedure for interagency data exchange and responsibility of data owners;

   2.5. order of public disclosure of anonymized data.

3. Determine the ESUC operator and its powers (Appendix No. 2).

4. Establish requirements for information security and protection of personal data (links to 152FZ, PP 1119, FSTEC orders, etc.).

5. Establish the implementation stages (MVP, pilot, scaling, federal launch) and targets.

6. This resolution shall enter into force on the date of its official publication.

Communication strategy and involvement of NGOs

Communications should be divided into 3 streams:

- NPO: "why do they need it" (reduce bureaucracy, one profile, confirmed transparency), training in statutes/reporting and profile, feedback. Reliance on the already existing digitalization of reporting/chartering as a “point of entry”. 

- Regions and departments: methodological packages according to data, KPIpanels, quality standards, "showcase of best practices". ?cite?turn24view0?  

- Public/business: public impersonal storefronts (project map, impact indicators), explanation of the link "SONCOstatus → trust/tax logic of donations". 

Channels: single ESUC website, webinars, FAQ, sandbox for developers, annual public report on data quality and effects.

KPI and success metrics

Operational KPI (data quality):

- coverage: the share of active NGOs with a completed "gold card";  

- freshness: median source update delay (SLA);  

- accuracy of comparison: the share of doubles / erroneous matches;  

- the proportion of records with a confirmed SONCOstatus;  

- the share of projects with a "planfakt" on financing and results.

Management KPI (effect):

- reducing the time of verification of NPOs/partners;  

- Percentage of support decisions made on the basis of a comparable KPI;  

- reduction of the share of financing "without result / without reporting" (according to the evaluation window). 

- growth of trust (polls), growth of the share of organizations with public charter and electronic reporting. 

Recommendations for the management of the “endowment circuit” and the creation of a public register of endowments

Problem: in the existence of a legal regime of target capital, data on the number of endowments, their size, management companies, target areas and results are disclosed heterogeneously (including the lack of a single register of target capital according to expert estimates). 

Decision in the ECSC: to create a separate sub-register ENDOWMENT_REG as a public layer associated with the “gold card of NGOs”, without disclosing excess personal data.

Minimum composition of public fields of the register of endowments:

- identifier of the owner of the target capital (OGRN/INN);  

- type of structure (within the NPO / specialized fund) - "requires clarification" on the format;  

- date of formation / threshold events;  

Targeted use of income (by reference);  

- management company (name, license - if applicable);  

- the value of the property of the target capital at the reporting date (ranges / aggregates);  

- income for the period and direction of distribution (aggregates);  

- reference to public reporting/audit (if available).

Regulatory framework:

- rely on the current law on target capital (including management and control requirements). 

- approve by a government act (or departmental act when delegating) the obligation to publish a minimum set of aggregated information in ENDOWMENT_REG (similar to the logic of statutes / reporting, but without "extra" PD). 

Levels of publicity:  

- PUBL1 (minimum): availability of target capital + Size Range;  

- PUBL2: + income/distribution by direction;  

- PUBL3: + Enhanced reporting and ESG metrics (voluntary, as a standard of "information openness").

This approach closes the main “gap of transparency” without substitution of corporate governance of endows and without duplicating the functions of other regulators.