Back to Presentation

PCRCI Knowledge Base

Everything you need to know about the Pre-Civil Registration Confidence Infrastructure.

Try: attestation, NFC, API, fraud, enrollment

Getting Started

What is PCRCI, how it works, and who it serves.

6 articles

Agents & Field Users

Agent login, enrollment, NFC cards, and attestation workflows.

7 articles

API & Integration

REST endpoints, authentication, webhooks, and code examples.

8 articles

Security & Privacy

Biometric hashing, fraud rules, audit trails, and compliance.

5 articles

Government & Institutions

KYC verification, confidence scores, thresholds, and onboarding.

5 articles

Technical Architecture

Offline-first design, database, sync, and deployment.

5 articles
No articles matched your search.

Getting Started

PCRCI (Pre-Civil Registration Confidence Infrastructure) is a system that turns community knowledge into structured, verifiable identity evidence for people who lack formal documentation.

Over 1 billion people worldwide exist outside formal identity systems. Without an ID, they cannot access banking, healthcare, land rights, or government services. PCRCI bridges this gap using community attestation — neighbours, elders, and local leaders vouch for a person's identity, building a confidence score that unlocks services progressively.

Built by Rifftlo Inc. (Delaware, USA), PCRCI operates in the Philippines, Papua New Guinea, Timor-Leste, Solomon Islands, Vanuatu, Fiji, and Indonesia.

The PCRCI pipeline has six steps:

  • Step 1 — Human Presence: The person comes first, before any document or credential.
  • Step 2 — Biometric & Voice Capture: Offline, non-invasive, held with full consent. Only SHA-256 hashes are stored — never raw biometrics.
  • Step 3 — Community Attestation: Social recognition is converted into verifiable, signed evidence.
  • Step 4 — Identity Confidence Score: Trust is measured and weighted — not assumed or imposed.
  • Step 5 — Institutional Recognition: The first door opens — banking, healthcare, land registration.
  • Step 6 — National ID Integration: The transition to formal systems becomes seamless.

PCRCI has three primary user types:

  • Agent: A trained field worker who enrolls subjects and manages the enrollment device. Requires a government-issued promo code, biometric registration, and NFC badge.
  • Attestor: A community member (neighbour, elder, family, official) who vouches for a subject's identity. Registers with a government ID and face liveness check.
  • Subject: The person being identified. Receives an NFC card with their DID (Decentralized Identifier) and builds a confidence score through attestations.

The platform also has administrative roles: Administrator, Senior, Junior, Viewer, Auditor, and Government API access.

Every subject starts with a confidence score of 1 (self-enrollment). Attestations from community members add points based on the attestor's relationship type:

Attestor TypeWeight
Community member+1
Family member+2
Tribe/clan leader+3
Local leader+3
Local officer+4
Government officer+5

Score thresholds unlock services:

ScoreAccess Level
4+Basic — community services, national ID application
7+Standard — banking, healthcare
10+Enhanced — land registration, insurance
15+Full — KYC-compliant banking, all institutional services

Day-one markets: Philippines, Papua New Guinea, Timor-Leste, Solomon Islands, Vanuatu, Fiji, Indonesia.

Philippines languages (8): Tagalog, Cebuano, Ilocano, Waray, Kapampangan, Bikol, Hiligaynon, Pangasinan.

Pacific languages (6): Tok Pisin, Tetum, Bislama, Pijin, Fijian, Bahasa Indonesia.

All agent and admin interfaces also support English. The app uses text-to-speech and speech-to-text for accessibility in the field.

Every agent, subject, and attestor receives a DID in the format: did:pcrci:{country}:{uuid}

DIDs are never reused, even if a subject's NFC card is replaced. They serve as the permanent, privacy-preserving identifier across the system — written to NFC cards and used in all API lookups.

Agents & Field Users

Agents authenticate using two factors:

  • NFC badge tap: The agent's registered badge is read via NFC (NTAG215/216 cards with NDEF text records containing their DID).
  • Biometric verification: Fingerprint or Face ID via the device's local authentication.

On successful login, a session is created with a unique hash, and an agent_login event is recorded in the immutable activity log.

New agents register through a multi-step process:

  • Promo code: Enter a government-issued code (format: XXXX-XXXX-XXXX), validated against the backend.
  • ID upload: Upload government ID and a second form of identification. Face detection (MLKit) extracts face geometry and creates a SHA-256 hash.
  • Location capture: GPS coordinates are recorded as the agent's registered location (used for fraud geo-fencing).
  • NFC badge write: The agent's DID is written to their NFC badge.

Subject enrollment follows 8 steps:

  • 1. Language selection: Choose the subject's preferred language for TTS/STT.
  • 2. Consent: Subject gives informed consent, read aloud in their language.
  • 3. Name entry: Via voice (speech-to-text) or alphabet keyboard. Gender is also captured.
  • 4. Birthday: Estimated birth year or exact date, with voice parsing support.
  • 5. Location: GPS auto-detect with manual override for tribe/clan/village.
  • 6. Review: All details read aloud for confirmation.
  • 7. NFC card write: The subject's DID and biometric hash are written to their NFC card.
  • 8. Face photo: Optional face capture for biometric hash (SHA-256 only).

The entire flow works offline. Data is queued in SQLite and synced to Firestore when connectivity returns.

Attestors are community members who vouch for a subject's identity. They first register by uploading a government ID and passing a face liveness check.

To attest, the attestor taps the subject's NFC card, confirms the subject's identity, and records their attestation with a weight based on their relationship type (community, family, leader, official).

Multiple attestations from different people create a confidence network — each one adds points to the subject's confidence score, progressively unlocking services.

PCRCI uses NTAG215/216 NFC cards to store a subject's DID and biometric hash. Cards are written during enrollment and read at government kiosks or attestation points.

  • Write: During enrollment step 7, the agent's device writes the subject's DID to a blank NFC card.
  • Read: Tapping a card retrieves the DID for verification, attestation, or kiosk access.
  • Replace: If a card is lost or damaged, agents can issue a replacement card linked to the same DID.

Security rule: the same NFC card DID cannot be written twice — attempting it triggers a block and alert.

PCRCI is designed offline-first. All enrollment, attestation, and login operations work without internet connectivity.

Data is stored locally in SQLite and queued for sync. When the device reconnects, the sync service pushes all queued records to Firestore with retry logic and exponential backoff. Connectivity changes trigger sync automatically.

Subjects access government services by tapping their NFC card at a kiosk. The flow:

  • Tap & consent: Subject taps their card. A consent disclosure is shown and read aloud.
  • Face verification: Optional biometric re-authentication via face scan.
  • Access granted: If the subject's confidence score meets the required threshold, their identity is shared with the requesting institution.

The kiosk runs in full-screen mode and auto-resets after each session for privacy.

API & Integration

The PCRCI Government API is a read-only REST API that lets institutions verify subject identity without exposing PII. Two authentication methods:

  • API Key: Pass via X-API-Key header. Provisioned by an admin.
  • OIDC OAuth 2.0: Client credentials flow via POST /oauth/token. Returns a JWT for Bearer authentication.

Rate limits: 60 requests/minute per API key, 100/minute per IP address.

Core verification endpoints:

GET /gov/v1/verify/{country}/{did}
Full verification status — returns confidence score, threshold met, attestation count. No PII exposed.

GET /gov/v1/score/{country}/{did}
Score with next threshold progress — useful for showing how close a subject is to the next access level.

POST /gov/v1/batch-verify
Verify up to 100 subjects in a single request.

GET /gov/v1/kyc/{country}/{did}
KYC status and creditworthiness for financial institutions.

POST /gov/v1/emergency-lookup
Hospital emergency identity verification — expedited access for medical emergencies.

PCRCI sends real-time webhook notifications for 14 event types including threshold crossings, fraud alerts, and compliance events. Webhooks are scoped by institution type — banks, hospitals, NGOs, education, insurance, and microfinance each receive tailored payloads.

All webhooks are signed with HMAC-SHA256. Verify the X-PCRCI-Signature header against the raw request body using your webhook secret. Always use timing-safe comparison.

Copy-paste examples available in Python, Node.js, and cURL:

  • Python: Verify subject, KYC check, batch verify, emergency lookup using requests library.
  • Node.js: Verify subject with fetch, webhook consumer with Express.
  • cURL: Quick terminal commands for testing all major endpoints.

Start with sandbox testing using your sandbox API key at /gov/v1/sandbox/ endpoints, which return deterministic mock data.

The sandbox environment provides deterministic mock data for development and testing:

  • Sandbox endpoints: /gov/v1/sandbox/verify/{country}/{did} — identical response format to production.
  • Mock data generation: POST /gov/v1/sandbox/data/generate/{type} — create test subjects, attestations, and fraud scenarios.
  • Sandbox API keys are issued separately and cannot access production data.

Before going live, complete the 13-point production checklist covering error handling, rate limit compliance, webhook verification, and security review.

CodeMeaning
400Bad request — invalid parameters or malformed body.
401Unauthorized — missing or invalid API key / token.
403Forbidden — valid credentials but insufficient permissions.
404Not found — subject DID does not exist in the specified country.
409Conflict — duplicate operation (e.g., NFC card already written).
429Rate limited — exceeded 60 requests/minute. Retry after cooldown.
500Internal server error — contact support.

PCRCI supports integration with legacy systems used by central banks and government mainframes:

  • SOAP/XML: WSDL endpoint at /gov/soap?wsdl with VerifySubject, BatchVerify, and KYCCheck operations.
  • COBOL: Fixed-width batch file processing (80/132 byte records) with COPYBOOK files. Transfer via SFTP, poll for results.
  • ISO 20022: Central bank and SWIFT-compatible message formats for financial integration.
  • Batch file: CSV and fixed-width formats with async processing and result polling.

All legacy endpoints support the same API key authentication. EBCDIC-safe character handling is documented for mainframe environments.

Institutions can register for API access via self-service:

POST /gov/v1/onboard
Submit your institution details (name, type, country, contact). Rate-limited to prevent abuse.

After submission, a PCRCI administrator reviews and approves the request. Once approved, you receive your API key and webhook secret. You can check your onboarding status at any time:

GET /gov/v1/onboard/{id}

Security & Privacy

PCRCI never stores raw biometric data. Face geometry is extracted via MLKit, then immediately hashed with SHA-256. Only the hash is stored and transmitted. This is a non-negotiable design principle.

Biometric hashes are used for deduplication (detecting if two enrollments are the same person) and re-authentication at kiosks. The original images are discarded after hashing.

Six automated fraud rules protect the system:

RuleAction
Attestor > 20 attestations in 7 daysAuto-suspend attestor
Attestor attests subject from same agent sessionBlock attestation
Two biometric hashes > 90% similarFlag both subjects
Agent enrolls > 500m outside registered GPSWarn + log
Agent > 8 enrollments per hourFlag agent
Same NFC card DID written twiceBlock + alert

Every action in PCRCI is recorded in an append-only, hash-chained activity log. No entry can be modified or deleted — enforced at both the application level and by Firestore security rules.

Each log entry contains: event type, actor DID, subject DID, payload, timestamp, and a SHA-256 hash that chains to the previous entry (genesis entry uses 64 zeros). This creates a tamper-evident record.

Event types include: agent_login, enrollment, nfc_write, attestation, fraud_flag, gov_consent, gov_access, and admin_action.

All backend endpoints are protected by RBAC. Roles and their capabilities:

  • Administrator: Full access — user management, fraud review, audit export, webhook config, API key provisioning.
  • Senior: Enrollment, fraud review, audit log read.
  • Junior: Enrollment and attestation only.
  • Viewer: Read-only dashboard access.
  • Auditor: Audit log access and export.
  • Agent: Field enrollment and attestation.
  • Government API: External API access only.

Roles are stored as Firebase Auth custom claims and enforced by middleware on every request.

PCRCI aligns with major regulatory frameworks:

  • FATF: Know-Your-Customer (KYC) guidelines for financial inclusion.
  • World Bank ID4D: Identification for Development principles.
  • eIDAS: Electronic identification standards (EU-compatible).
  • ISO/IEC 29115: Entity authentication assurance framework.
  • ISO 27001: All admin requests are logged in a compliance audit trail.

TLS 1.2+ is enforced on all connections. All data at rest is encrypted via Firebase/Google Cloud default encryption.

Government & Institutions

Banks and microfinance institutions can verify subject identity and creditworthiness via the KYC endpoint:

GET /gov/v1/kyc/{country}/{did}

Returns confidence score, threshold status, attestation history, and a KYC recommendation — all without exposing personal data. The institution decides whether to approve access based on the score and their own policies.

PCRCI uses progressive trust — subjects gain access to services as their confidence score grows:

  • 4+ points: Basic community services, NGO aid distribution, national ID application.
  • 7+ points: Standard access — banking (savings accounts), healthcare registration, education enrollment.
  • 10+ points: Enhanced access — land registration, insurance, microfinance loans.
  • 15+ points: Full integration — KYC-compliant banking, all institutional services.

Thresholds are configurable per country to align with local regulations and institutional requirements.

PCRCI sends scoped webhook notifications tailored to each institution type:

  • Banks: KYC status, credit eligibility, score threshold crossings.
  • Hospitals: Emergency identity verification, healthcare eligibility.
  • NGOs: Aid distribution eligibility, beneficiary verification.
  • Education: Student identity verification, enrollment eligibility.
  • Insurance: Policy eligibility, identity confidence for underwriting.
  • Microfinance: Small loan eligibility, community trust metrics.

Hospitals can perform expedited identity verification for medical emergencies:

POST /gov/v1/emergency-lookup

This endpoint bypasses normal rate limits for urgent situations. It returns basic identity confirmation and any registered medical flags, without exposing full personal data. All emergency lookups are logged and auditable.

Aggregate, anonymized statistics per country are available at:

GET /gov/v1/stats/{country}

Returns total enrollments, active agents, attestation counts, average confidence scores, and threshold distribution — no PII is included. Useful for government reporting and program evaluation.

Technical Architecture

  • Mobile/Web app: Flutter 3.x (Dart) — single codebase for Android, iOS, and Web.
  • State management: Riverpod with GoRouter for navigation.
  • Local database: SQLite (sqflite) for offline-first operation.
  • Cloud database: Cloud Firestore (asia-southeast1) — append-only, multi-tenant by country.
  • Authentication: Firebase Auth with custom claims for RBAC.
  • Backend API: FastAPI (Python) on Google Cloud Run.
  • AI/ML: Google MLKit (face detection), Gemini/Claude/GPT-4o (fraud review).
  • NFC: nfc_manager package (NTAG215/216).
  • Biometrics: local_auth (fingerprint/Face ID).

Every write operation goes to SQLite first, then queues for Firestore sync. The sync service:

  • Monitors connectivity via connectivity_plus.
  • Automatically triggers sync when the device comes online.
  • Uses exponential backoff for failed syncs.
  • Maintains a sync queue with status tracking per record.

This ensures zero data loss — even if the device is offline for days, all records will sync when connectivity returns.

All Firestore data is namespaced by country code: /{country}/{collection}/{docId}

Supported namespaces: ph (Philippines), pg (PNG), tl (Timor-Leste), sb (Solomon Islands), vu (Vanuatu), fj (Fiji), id (Indonesia).

This ensures complete data isolation between countries while sharing the same infrastructure and codebase.

  • Backend: FastAPI on Google Cloud Run (asia-southeast1), auto-scaled 0–5 instances, 512MB memory.
  • Web app: Flutter web build deployed to Firebase Hosting.
  • Android: APK built with flutter build apk --release.
  • CI/CD: Cloud Build via cloudbuild.yaml.
  • Estimated cost: $160–365/month at 1M users (conservative $350–500/month including all services).

PCRCI is designed to be extremely cost-efficient:

  • Firestore: ~$81/month reads + ~$97/month writes at 1M users.
  • Cloud Run: $30–80/month typical (auto-scales to zero when idle).
  • Cloud Storage: $0.26–1/month for ID photos and documents.
  • Firebase Hosting: Free tier covers web app.

Budget alerts are configured at $50, $100, and $200 thresholds. Cost per enrolled subject is under $2.