MCC Registry — KYC and Account Opening Procedure v1.0

Instrument: Operational procedure under MCC-800 Registry Operations Standard v1.1 §5.2 (arts. 32–37) and the Registry Terms v1.1 Article 3 (Tier 5; 14 days' notice, MCC-001 cl. 0083) Status: v1.0 DRAFT for adoption under FD-2026-08-24 item 3 — NOT ADOPTED Owner: Registry Manager · Oversight: Registry Oversight Authority (MCC-700 §4.3; the Board until appointed) Prepared: 25 August 2026

1. Purpose and scope

Every registry account holder is a party that can hold, transfer or retire MCC units and make claims on them. The programme must know who that party is, that it is not sanctioned or debarred, and who is authorised to act for it — before the first unit reaches the account. This procedure applies to every organisation account (project developer, VVB, buyer, intermediary, host-country entity, NGO) and to every change of authorised representative or beneficial ownership thereafter. Individual accounts are not offered at launch (Registry Terms art. 3.1 contemplates them; the platform issues organisation accounts only).

2. Roles

3. Evidence required (Registry Terms art. 3.1–3.3; MCC-800 art. 32)

1. Legal entity: registered name, registration number, jurisdiction, registered address (not a PO box); extract from the national register dated within 3 months, uploaded to the document store (SHA-256 recorded on upload).
2. Beneficial ownership: every natural person holding > 10 % or otherwise controlling the entity; for listed companies, regulated financial institutions, public bodies and multilateral organisations, a statement to that effect replaces the list.
3. Authorised representatives: name, role, work e-mail, government-issued identity document seen (number and expiry recorded; the document itself is not retained unless the jurisdiction requires it); a board resolution or power of attorney where the representative is not a registered signatory.
4. Sector classification and intended use of the account (developer / VVB / buyer / intermediary / other).
5. Anti-fraud declaration (art. 3.3) and acceptance of the Registry Terms v1.1, signed in the platform by the representative (name + hash + timestamp).
6. For VVB organisations: the accreditation record at /portal/admin/vvb (an account may be opened at APPLICATION_SUBMITTED; engagement assignment is separately gated on accreditation).

4. Checks

4.1 Identity and existence. Registration number and name verified against the national register (Brønnøysundregistrene, Companies House, RNE Tunisia, etc.) or, where no online register exists, against a notarised extract. Mismatch → request for clarification (10 days, art. 3.1); unresolved → refusal.

4.2 Sanctions and debarment. The entity, each beneficial owner and each authorised representative screened against: UN Security Council consolidated list; EU consolidated list; OFAC SDN and consolidated lists; the World Bank and other MDB debarment lists; the Norwegian sanctions register. Screening is performed at application, at every change under §6, and re-run for all account holders every 12 months. Until a screening tool is integrated with the platform, the RM performs the searches manually and records for each name: list, date, search string, result, screenshot or export saved to the document store. A true hit → refusal with grounds (art. 3.2), PA co-signature, and referral where the law requires. A possible match (name similarity) → resolved by identifiers (date of birth, registration number) and documented; unresolved possible matches are treated as hits.

4.3 Adverse information. A documented open-source check (regulator actions, fraud or environmental-crime convictions, debarment from development programmes) on the entity and its principals, proportionate to risk tier (§5). Findings are weighed against the anti-fraud declaration; a false declaration is grounds for refusal and, later, suspension (art. 3.3).

4.4 Authority. That the representative is entitled to bind the entity (register extract or resolution/POA), and that the e-mail domain belongs to the entity (or an explanation is recorded).

4.5 Purpose and plausibility. That the stated use fits the sector classification and the programme (a "buyer" that is a project developer's affiliate is classified as a developer and treated under MCC-CADCP exclusivity rules; a VVB may not also hold a developer or buyer account — MCC-400 art. 15).

5. Risk tiers and refresh

6. Ongoing obligations

Account holders notify changes of representatives, ownership or status within 5 business days (MCC-800 art. 35); the RM re-runs §4 on the changed element. Failure to notify, a screening hit on refresh, or an investigation under MCC-800 art. 105 → temporary restriction (block transfers/retirements) communicated within 24 hours (art. 37, 105), escalated to suspension by the PA if unresolved in 30 days.

7. Records and the platform

The determination is recorded on the organisation: verified = true, verifiedAt, verifiedBy (the RM), with the evidence files and screening exports attached as documents (hash-recorded). A refusal is recorded as verified = false with a note and the refusal letter attached; the audit log carries the action. Personal data is retained for the life of the account plus seven years (MCC-700 §14.2), minimised to what §3 requires, and never published; only the organisation's registered name appears on public registry surfaces.

8. Timelines

Acknowledge within 2 business days; determination within 10 business days of a complete application (MCC-800 art. 33); clarification requests pause the clock, with 10 days to respond (art. 3.1). Refusals state grounds and the appeal route.

9. Known gaps (to close before first external account)

Sanctions screening is manual (no tool integrated); the platform has no "risk tier" field (recorded in the verification note until added); individual accounts are not supported. Programme fees for account registration are those of the Fee Schedule adopted under FD-2026-08-24 item D9.

Change log — v1.0 DRAFT (25 Aug 2026): first issue.