Registry KYC and Account Opening Procedure v1.0
New procedure under MCC-800 v1.1 §5.2 and the Registry Terms v1.1 Article 3
What is being consulted on
How the registry verifies who an account holder is before the first unit reaches the account: evidence required, identity and sanctions checks, risk tiers, refresh cycle, records, timelines — and the known gaps to close before the first external account.
- Decision by
- Programme administration under FD-2026-08-24 item 3, with Registry Oversight Authority oversight (MCC-001 cl. 0083)
- After closing
- Every material comment receives a written response; the closing protocol is published here; the decision cites the proposal by its hash; on adoption the text is published at /transparency/documents with a version bump and this consultation is linked from it.
- Proposal SHA-256
1a26e33bc0759d95600532d35b1fdf4939f8b19dcc1a610ab9e7d927d2ea8a6d- Source file
- MCC_KYC_and_Account_Opening_Procedure_v1.0_DRAFT.md
Proposal text hash 1a26e33b…d2ea8a6d
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
| Role | Does | May not |
|---|---|---|
| Applicant's authorised representative | Submits the application and evidence; signs the declarations (D10) | — |
| Registry Manager (RM) | Performs checks 4.1–4.5; records the determination; approves or refuses | Approve an account for an organisation in which the RM or a close relation has an interest (MCC-700 §13) |
| Programme Administrator (PA) | Second signature on any refusal, any approval with a screening hit or a PEP/high-risk classification, and any account for a VVB or a governance body | — |
| Registry Oversight Authority | Quarterly sample review of determinations; annual report | — |
3. Evidence required (Registry Terms art. 3.1–3.3; MCC-800 art. 32)
- 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).
- 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.
- 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.
- Sector classification and intended use of the account (developer / VVB / buyer / intermediary / other).
- Anti-fraud declaration (art. 3.3) and acceptance of the Registry Terms v1.1, signed in the platform by the representative (name + hash + timestamp).
- 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
| Tier | Criteria | Extra measures | Refresh |
|---|---|---|---|
| Standard | Registered entity in a jurisdiction with an online register; no hits; no PEP | — | 24 months |
| Enhanced | PEP among principals; jurisdiction without online register or on FATF grey/black list; complex ownership (> 2 layers); intermediary/trader; unresolved possible match at first pass | Source-of-funds statement for purchases > EUR 50 000; PA co-signature; annual refresh; senior-management sign-off on the first transfer | 12 months |
| Refuse | True sanctions hit; debarment; false declaration; identity not established | Refusal letter with grounds; appeal under MCC-700 §15 | — |
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.
Public comments 0 received · 0 answered
No comments have been submitted yet.