04_PHILSYS_KYC_INTEGRATION_SPEC.md

PhilSys KYC Integration Specification

1. PhilSys API Integration Overview

1.1 PhilSys Framework

• Philippine Identification System (PhilSys) administered by the Philippine Statistics Authority (PSA) and the Department of Information and Communications Technology (DICT)
• Legal basis: Republic Act No. 11055 (Philippine Identification System Act), enacted September 2018
• PhilID: Physical national ID card with QR code containing demographic and biometric data in encrypted form
• PhilSys Number: Unique 12-digit identification number assigned to each registered person
• PhilSys Check Digit: Algorithmically computed check digit for PhilSys Number validation (Luhn algorithm variant)
• PhilSys API: Government-provided identity verification service for accredited relying parties, managed through the DICT Government Service Bus (GSB)

1.1.1 Regulatory References

Regulation	Citation	Relevance
RA 11055	Philippine Identification System Act	Establishes PhilSys, defines relying party obligations
RA 10173	Data Privacy Act of 2012	Governs personal data processing, consent, data subject rights
RA 9160	Anti-Money Laundering Act (AMLA)	KYC/AML requirements for covered persons
RA 10175	Cybercrime Prevention Act of 2012	Digital evidence, electronic signature validity
BSP Circular No. 1098	Regulations on E-Money Issuers	BSP licensing requirements for payment services
NPC Advisory No. 2024-01	NPC Guidelines on PhilSys Processing	NPC-specific guidance on PhilSys data handling
NPC Circular No. 16-03	Security Measures for Personal Data	Required organizational, physical, and technical measures

1.1.2 Relying Party Obligations

Under RA 11055 Section 23 and its IRR, relying parties must:

1. Obtain explicit, informed consent before accessing PhilSys data
2. Use PhilSys data only for the declared and consented purpose
3. Implement appropriate security measures per NPC Circular No. 16-03
4. Not store the PhilSys Number in plain text (hashed or tokenized storage only)
5. Not store biometric data received through PhilSys verification
6. Maintain audit logs of all PhilSys verification requests for minimum 5 years
7. Report any data breach involving PhilSys data to NPC within 72 hours per RA 10173 Section 20
8. Allow data subjects to exercise their rights under RA 10173 Chapter III

1.2 Platform Integration Model

1.2.1 Architecture

┌─────────────┐     ┌──────────────────┐     ┌────────────────────┐
│  User App /  │────▶│  Platform KYC    │────▶│  PhilSys           │
│  Agent App   │     │  Service         │     │  Verification API  │
└─────────────┘     └──────────────────┘     └────────────────────┘
                           │                          │
                           ▼                          ▼
                    ┌──────────────┐          ┌──────────────────┐
                    │  Obligation  │          │  PSA/PSA-Auth     │
                    │  Ledger      │          │  Identity Store   │
                    └──────────────┘          └──────────────────┘

• Platform acts as a Relying Party under the PhilSys framework
• Integration via DICT/PSA-provided PhilSys Verification API accessible through the Government Service Bus (GSB)
• Accreditation required: Relying Party Agreement with PSA, DICT GSB onboarding, NPC registration as Personal Information Controller (PIC)

1.2.2 Authentication & Security

Layer	Mechanism	Details
Transport	Mutual TLS (mTLS)	X.509 client certificate issued by PSA/PSA-CA, TLS 1.3 minimum
API Access	API Key	Issued during GSB onboarding, rotated every 90 days
Authorization	OAuth 2.0 Client Credentials	Bearer token, 1-hour expiry, scoped to verification endpoints
Request Signing	HMAC-SHA256	Each request body signed with platform private key; signature in X-Request-Signature header
Replay Protection	Nonce + Timestamp	X-Request-Nonce (UUID v4) + X-Request-Timestamp (ISO-8601, within 5-minute window)
Rate Limiting	Token bucket	100 requests/minute per API key, 10,000 requests/day

1.2.3 Data Minimization Principles

• Platform receives only verification results and confirmed identity attributes — not raw biometric data
• Platform stores only the minimum identity attributes required for the applicable KYC tier
• PhilSys Number is never stored in plain text — SHA-256 hash with per-tenant salt used for deduplication
• Verification results stored with request ID, timestamp, and full audit trail in the Obligation Ledger's compliance event stream
• All PhilSys-related data encrypted at rest using AES-256-GCM with envelope encryption (KMS-managed data keys)

1.3 PhilSys API Endpoints

1.3.1 Primary Endpoints

Endpoint	Method	Purpose	Request	Response
/api/v1/verify	POST	Verify PhilSys Number + demographic data	PhilSys Number, name, DOB, address, consent reference	Match result, confidence score, verified attributes
/api/v1/verify/biometric	POST	Verify biometric match (fingerprint/iris, if available)	PhilSys Number, biometric template, consent reference	Biometric match result, confidence score
/api/v1/status/{request_id}	GET	Check verification request status	Request ID	Status: pending, completed, failed, error
/api/v1/consent	POST	Register explicit consent for verification	User ID, purpose code, consent text version, digital signature	Consent acknowledgment with consent ID
/api/v1/consent/{consent_id}/revoke	POST	Revoke previously granted consent	Consent ID, revocation reason	Revocation confirmation
/api/v1/accreditation/status	GET	Check platform accreditation status	—	Accreditation status, expiry date, scope

1.3.2 Request/Response Schemas

POST /api/v1/verify — Request

{
  "philsys_number": "1234-5678-9012-3456",
  "demographic_data": {
    "full_name": "Juan Dela Cruz",
    "date_of_birth": "1990-01-15",
    "sex": "M",
    "address": "123 Rizal Street, Barangay San Antonio, Makati City, 1203 Metro Manila"
  },
  "consent_reference": {
    "consent_id": "550e8400-e29b-41d4-a716-446655440000",
    "purpose_code": "P001",
    "consent_timestamp": "2026-04-07T09:30:00+08:00"
  },
  "requesting_party": {
    "rp_id": "RP-2026-AGRIFIN-001",
    "rp_name": "AgriFinance Platform",
    "operator_id": "OP-001"
  },
  "request_metadata": {
    "request_id": "req-uuid-v4",
    "timestamp": "2026-04-07T09:30:05+08:00",
    "nonce": "uuid-v4",
    "channel": "mobile_app|web_portal|agent_app|api"
  }
}

POST /api/v1/verify — Response

{
  "request_id": "req-uuid-v4",
  "status": "completed",
  "verification_result": {
    "match_status": "MATCH|NO_MATCH|PARTIAL_MATCH|NOT_FOUND|ERROR",
    "confidence_score": 95,
    "verified_at": "2026-04-07T09:30:06+08:00",
    "verified_attributes": {
      "full_name": {
        "provided": "Juan Dela Cruz",
        "verified": "Juan Dela Cruz",
        "match": true
      },
      "date_of_birth": {
        "provided": "1990-01-15",
        "verified": "1990-01-15",
        "match": true
      },
      "address": {
        "provided": "123 Rizal Street, Barangay San Antonio, Makati City",
        "verified": "123 Rizal St., Brgy. San Antonio, Makati City, 1203 Metro Manila",
        "match": true,
        "note": "Minor formatting difference, confirmed same address"
      }
    },
    "philsys_status": "ACTIVE|INACTIVE|DECEASED|DUPLICATE",
    "warnings": []
  },
  "audit": {
    "philsys_request_id": "PSA-REQ-20260407-000001",
    "processing_time_ms": 1250
  }
}

GET /api/v1/status/{request_id} — Response

{
  "request_id": "req-uuid-v4",
  "philsys_request_id": "PSA-REQ-20260407-000001",
  "status": "pending|completed|failed|error",
  "submitted_at": "2026-04-07T09:30:05+08:00",
  "completed_at": "2026-04-07T09:30:06+08:00",
  "error": null
}

1.4 Integration Flow

1.4.1 Standard Verification Flow

Sequence: Standard PhilSys Verification

User/Agent          Platform KYC Service        PhilSys API          Obligation Ledger
    │                      │                        │                      │
    │──(1) Submit PhilSys─▶│                        │                      │
    │    Number + consent  │                        │                      │
    │                      │                        │                      │
    │                      │──(2) Validate consent──│                      │
    │                      │    record              │                      │
    │                      │                        │                      │
    │                      │──(3) Hash PhilSys No.──│                      │
    │                      │    (dedup check)       │                      │
    │                      │                        │                      │
    │                      │──(4) POST /verify─────▶│                      │
    │                      │    (mTLS + OAuth2 +    │                      │
    │                      │     HMAC signature)    │                      │
    │                      │                        │                      │
    │                      │◀──(5) Verification─────│                      │
    │                      │    result              │                      │
    │                      │                        │                      │
    │                      │──(6) Determine KYC     │                      │
    │                      │    tier based on       │                      │
    │                      │    confidence score    │                      │
    │                      │                        │                      │
    │                      │───────────────────────▶│──(7) Record KYC      │
    │                      │                        │    event, audit trail│
    │                      │                        │                      │
    │◀──(8) Confirmation───│                        │                      │
    │    (tier assigned)   │                        │                      │

1.4.2 Flow Steps Detail

1. User provides PhilSys Number and explicit consent

   • Consent captured digitally with timestamp, IP address, device fingerprint, session ID
   • Consent displayed in user's preferred language (Filipino, English, or local dialect)
   • Digital signature captured via touchscreen or typed name confirmation
   • Consent statement (Filipino): "Sa pagbibigay ng inyong PhilSys Number, pinahihintulutan ninyo ang [Platform Name] na beripikahin ang inyong pagkakakilanlan sa pamamagitan ng Philippine Statistics Authority. Ang inyong data ay gagamitin lamang para sa [Layunin: KYC verification, program eligibility] at protektado sa ilalim ng Republic Act 10173 (Data Privacy Act). Maaari ninyong bawiin ang inyong pahintulot anumang oras."
   • Consent statement (English): "By providing your PhilSys Number, you authorize [Platform Name] to verify your identity through the Philippine Statistics Authority. Your data will be used solely for [Purpose: KYC verification, program eligibility] and will be protected under Republic Act 10173 (Data Privacy Act). You may revoke this consent at any time."

2. Platform validates consent record

   • Verify consent record exists with purpose code P001 (KYC/Identity verification via PhilSys)
   • Verify consent is signed and not revoked
   • Verify consent is current (within validity period defined by platform policy)
   • If consent validation fails, halt process and request new consent

3. Platform performs deduplication check

   • Hash provided PhilSys Number with platform salt (SHA-256)
   • Check against existing golden records to detect duplicate onboarding attempts
   • If duplicate found, link to existing record or flag for manual review

4. Platform submits verification request to PhilSys API

   • Request includes: PhilSys Number, demographic data for matching (name, date of birth, address), consent reference ID, requesting party ID
   • Request signed with HMAC-SHA256 using platform private key
   • mTLS connection established with PSA-issued client certificate
   • OAuth 2.0 bearer token attached for authorization

5. PhilSys API returns verification result

   • Match status: MATCH, NO_MATCH, PARTIAL_MATCH, NOT_FOUND, ERROR
   • Confidence score: 0-100
   • Verified attributes: name, DOB, address (only confirmed fields returned)
   • PhilSys account status: ACTIVE, INACTIVE, DECEASED, DUPLICATE

6. Platform updates user KYC status based on result

   • MATCH with confidence >= 85: auto-approve Tier 2
   • PARTIAL_MATCH with confidence 60-84: flag for manual review by compliance officer
   • Confidence < 60 or NO_MATCH: reject, inform user, offer alternative verification path
   • ERROR: retry (max 3 attempts with exponential backoff), then escalate to support

7. Verification result recorded in Obligation Ledger

   • Event type: kyc_verification_completed
   • Includes: request ID, match status, confidence score, tier assigned, timestamp, operator ID
   • Immutable audit trail entry with cryptographic hash linking to previous event

8. User notified of outcome

   • Confirmation via SMS, email, or in-app notification
   • If rejected, provide reason and alternative onboarding options
   • If manual review required, provide expected timeline (48 hours maximum)

1.4.3 Error Handling

Error Scenario	Response	Retry Strategy	Escalation
PhilSys API timeout (>30s)	Return "verification pending" to user	Retry 3x with exponential backoff (1s, 2s, 4s)	After 3 retries: queue for async processing
PhilSys API returns ERROR	Log error, return generic message to user	No retry (likely systemic issue)	Alert ops team, check PSA status page
Invalid PhilSys Number format	Return format error to user immediately	No retry	N/A
Consent not found or revoked	Request new consent from user	N/A	N/A
mTLS certificate expired	Block all requests	N/A	Critical: rotate certificate immediately
OAuth token expired	Refresh token and retry	1 retry with fresh token	If refresh fails: check client credentials
Rate limit exceeded	Queue request	Retry after rate limit window	Monitor usage patterns, request limit increase if needed
Duplicate PhilSys Number detected	Link to existing record or flag	N/A	Manual review for potential identity fraud

---

2. Explicit Consent Capture

2.1 Consent Capture Requirements

Consent for PhilSys data processing must satisfy all requirements under RA 10173 (Data Privacy Act of 2012) Section 12 and NPC issuances:

Requirement	Description	Implementation
Informed	User must understand what data is collected, why, and how it will be used	Multi-language consent form with plain-language explanation
Specific	Consent must be for a clearly defined purpose	Purpose code P001 specifically for KYC/identity verification via PhilSys
Current	Consent must not be stale or expired	Consent validity period: 12 months from grant date
Freely given	User must have genuine choice; no coercion	Service cannot be denied if user chooses alternative verification path
Explicit	Clear affirmative action required	Digital signature, checkbox + typed confirmation, or biometric consent
Documented	Consent must be recorded and retrievable	Immutable consent record in Obligation Ledger with cryptographic hash
Revocable	User can withdraw consent at any time	Revocation endpoint, immediate cessation of processing (subject to AMLA legal basis)

2.1.1 Consent Language Requirements

Consent must be displayed in the user's preferred language:

Language	Code	Required For
Filipino	fil	National default
English	en	Business/technical contexts
Cebuano	ceb	Visayas and Mindanao regions
Ilocano	ilo	Ilocos Region
Hiligaynon	hil	Western Visayas
Waray	war	Eastern Visayas
Kapampangan	pam	Central Luzon
Bicolano	bik	Bicol Region

Platform detects user's preferred language based on: device language setting, geographic location (barangay-level), user profile preference, or agent selection during assisted onboarding.

2.1.2 Consent Statement Templates

Filipino (Default):

Sa pagbibigay ng inyong PhilSys Number, pinahihintulutan ninyo ang [Platform Name] na beripikahin
ang inyong pagkakakilanlan sa pamamagitan ng Philippine Statistics Authority. Ang inyong data ay
gagamitin lamang para sa [Layunin] at protektado sa ilalim ng Republic Act 10173 (Data Privacy
Act). Maaari ninyong bawiin ang inyong pahintulot anumang oras sa pamamagitan ng pag-contact sa
aming Data Protection Officer sa [DPO contact info].

English:

By providing your PhilSys Number, you authorize [Platform Name] to verify your identity through
the Philippine Statistics Authority. Your data will be used solely for [Purpose] and will be
protected under Republic Act 10173 (Data Privacy Act). You may revoke this consent at any time
by contacting our Data Protection Officer at [DPO contact info].

2.2 Consent Record Schema

2.2.1 Consent Record (Full)

{
  "consent_id": "550e8400-e29b-41d4-a716-446655440000",
  "user_id": "usr-001",
  "purpose_code": "P001",
  "purpose_description": "KYC/Identity verification via PhilSys",
  "consent_text_version": "v2.1-fil-2026Q1",
  "consent_text_hash": "sha256:abc123...",
  "consent_given_at": "2026-04-07T09:30:00+08:00",
  "consent_method": "digital_signature",
  "consent_channel": "mobile_app",
  "signature": {
    "type": "digital",
    "method": "typed_name_confirmation|touchscreen_signature|biometric_ack",
    "signature_data": "base64_encoded_signature_image_or_hash",
    "witness_id": null
  },
  "ip_address": "203.177.100.50",
  "device_fingerprint": "fp-abc123def456",
  "session_id": "sess-uuid-v4",
  "language": "fil",
  "consent_displayed": {
    "full_text_shown": true,
    "scroll_depth": 100,
    "time_spent_seconds": 45,
    "language_version": "fil"
  },
  "data_categories": [
    "identity_verification",
    "demographic_data",
    "verification_result"
  ],
  "receiving_parties": [
    "PSA (Philippine Statistics Authority)",
    "DICT (Department of Information and Communications Technology)"
  ],
  "retention_until": "2031-04-07T09:30:00+08:00",
  "revoked": false,
  "revoked_at": null,
  "revocation_reason": null,
  "created_at": "2026-04-07T09:30:00+08:00",
  "updated_at": "2026-04-07T09:30:00+08:00"
}

2.2.2 Consent Purpose Codes

Code	Purpose	Data Categories	Retention	Revocation Impact
P001	KYC/Identity verification via PhilSys	Identity verification, demographic data, verification result	5 years post-closure	Processing stops; AMLA legal basis may continue
P002	Transaction monitoring & AML screening	Transaction data, risk scoring, screening results	5 years from event	AMLA legal basis continues independently
P003	Program eligibility verification	Program enrollment, eligibility criteria, benefit history	Duration of program + 3 years	May affect program enrollment
P004	Cross-agency data sharing	Shared demographic data, program participation	Per DPA between agencies	Data sharing stops; existing shared data unaffected
P005	Communications & notifications	Phone number, email, preferred language, notification preferences	Until consent revoked	Notifications cease

2.2.3 Consent Revocation

{
  "consent_id": "550e8400-e29b-41d4-a716-446655440000",
  "revoked": true,
  "revoked_at": "2026-06-15T14:22:00+08:00",
  "revocation_method": "user_request|agent_assisted|system_expiry",
  "revocation_reason": "User requested withdrawal of consent",
  "revocation_channel": "mobile_app|agent_app|api|email",
  "impact_assessment": {
    "kyc_tier_affected": true,
    "downgrade_to_tier": 0,
    "amla_processing_continues": true,
    "data_deletion_scheduled": false,
    "notification_sent": true
  },
  "revoked_by": "user|agent|system"
}

2.3 Data Minimization Practices

2.3.1 Data Storage Matrix

Data Received from PhilSys	Stored by Platform	Storage Format	Used For	Retained Until	Legal Basis
Verification result (MATCH/NO_MATCH)	Yes	Plain text in encrypted DB	KYC tier upgrade, audit trail	5 years post-closure	AMLA RA 9160 Sec. 9
Verified name	Yes	Encrypted (AES-256-GCM)	Identity record, golden record	5 years post-closure	AMLA RA 9160 Sec. 9
Verified date of birth	Yes	Encrypted (AES-256-GCM)	Age verification, transaction limits	5 years post-closure	AMLA RA 9160 Sec. 9
Verified address	Yes	Encrypted (AES-256-GCM)	Geographic compliance, program eligibility	5 years post-closure	AMLA RA 9160 Sec. 9
PhilSys Number	Hashed only	SHA-256 with per-tenant salt	Deduplication, MDM golden record key	Never stored in plain text	RA 11055 Sec. 23
Photo/biometric	No	Not stored	N/A	N/A	RA 11055 Sec. 23(c)
Raw PhilSys API response	Yes	Encrypted, limited access (role-based)	Audit trail, dispute resolution	5 years	AMLA RA 9160 Sec. 9
Confidence score	Yes	Plain text	Tier determination	5 years post-closure	AMLA RA 9160 Sec. 9
PhilSys account status	Yes	Plain text	Risk assessment	5 years post-closure	AMLA RA 9160 Sec. 9

2.3.2 Encryption Standards

Data Category	Encryption at Rest	Encryption in Transit	Key Management
PhilSys Number hash	N/A (one-way hash)	TLS 1.3	SHA-256 with per-tenant salt
Verified identity attributes	AES-256-GCM	TLS 1.3	AWS KMS / GCP Cloud KMS, envelope encryption
Raw API responses	AES-256-GCM	TLS 1.3	AWS KMS / GCP Cloud KMS, envelope encryption
Consent records	AES-256-GCM	TLS 1.3	AWS KMS / GCP Cloud KMS
Audit logs	AES-256-GCM (append-only)	TLS 1.3	KMS-managed keys, immutable ledger

2.3.3 Access Controls

Role	PhilSys Verification Result	Verified Identity Data	Raw API Response	Consent Records	Audit Logs
End User	Own data only	Own data only	No access	Own records	Own activity
Agent	No access	No access	No access	No access	Own activity
Compliance Officer	Yes	Yes	Yes (role-based)	Yes (related to investigation)	Yes
DPO	Yes	Yes	Yes	Yes	Yes
System Service	Yes	Yes	Yes	Yes	Yes
Administrator	No (principle of least privilege)	No	No	No	Yes

---

3. Tiered Identity Model

3.1 Tier Structure Overview

The platform implements a four-tier identity verification model that balances financial inclusion with regulatory compliance. Each tier provides progressively higher capabilities based on the depth of identity verification performed.

Tier	Name	Verification Method	Data Sources	Approval	Processing Time
Tier 0	Assisted/Basic	Agent-verified basic information	Agent attestation, basic demographic	Agent + system auto-approval	5-15 minutes
Tier 1	Government ID	Valid government-issued ID document	UMID, Passport, Driver's License, PRC ID, Voter's ID, Postal ID	Document verification + manual review	15-30 minutes
Tier 2	PhilSys-Linked	PhilSys Number verification via PSA API	PhilSys Verification API (DICT GSB)	System auto-approval on PhilSys match	5-10 minutes
Tier 3	Credit/Coop/SEC	Enhanced verification with credit/cooperative data	Credit bureau (CIC), cooperative membership, SEC records, TIN verification	Compliance officer approval	1-3 business days

3.2 Tier 0: Assisted/Basic

3.2.1 Overview

Agent-accredited individual vouches for user identity. This tier is designed for geographically isolated and disadvantaged areas (GIDA) where digital infrastructure is limited and users may not possess government-issued identification documents.

3.2.2 Onboarding Requirements

• Agent must be accredited by the platform (background check completed, training certification valid, bonding verified)
• Basic demographic data collected: full name, date of birth, barangay address
• Agent captures user photo via mobile app camera
• Geotag recorded at onboarding location (GPS coordinates with accuracy radius)
• Agent signs attestation on mobile app (offline-capable, syncs when connectivity restored)
• Agent attestation is legally binding under platform Agent Agreement

3.2.3 Data Collected

Data Field	Required	Verification Method
Full name	Yes	Agent attestation
Date of birth	Yes	Agent attestation (approximate if unknown)
Barangay address	Yes	Agent attestation + geotag
Phone number	Recommended	SMS OTP verification
User photo	Yes	Agent-captured via mobile app
Agent ID	Yes	Accredited agent credentials
Geotag	Yes	GPS coordinates + accuracy radius
Attestation signature	Yes	Digital signature on mobile app

3.2.4 Capability Limits

Parameter	Limit	Regulatory Reference
Maximum daily transactions	3	BSP Circular No. 1098
Maximum daily transaction value	PHP 10,000	BSP Circular No. 1098 (low-value tier)
Maximum monthly transaction value	PHP 50,000	BSP Circular No. 1098
Maximum single transaction value	PHP 5,000	BSP Circular No. 1098
Voucher receipt	Allowed (restricted categories only)	Program policy
Cash-out	Agent-mediated only	BSP Circular No. 1098
Cross-border payments	Not allowed	BSP FX regulations
Credit access	Not allowed	SEC lending regulations
Sub-program enrollment	Limited (basic distribution only)	Program policy
Upgrade deadline	Must upgrade to Tier 1 within 90 days	Platform policy

3.2.5 AML Screening

• Basic name screening against sanctions lists and PEP databases at onboarding
• Screening sources: UN Security Council Sanctions List, OFAC SDN List, BSP Financial Sanctions List
• Match threshold: exact name match + date of birth match (if available)
• Possible matches flagged for compliance officer review before activation

3.3 Tier 1: Government ID

3.3.1 Overview

Requires valid government-issued identification document. Designed for users who possess acceptable government IDs but have not yet registered for PhilSys or prefer not to link their PhilSys Number.

3.3.2 Accepted Identification Documents

Document Type	Issuing Authority	Verification Method	Validity Check
UMID (Unified Multi-Purpose ID)	SSS/GSIS	Document number + biographic data	SSS/GSIS verification API
Philippine Passport	DFA	Machine-readable zone (MRZ) scan	DFA verification API
Driver's License	LTO	License number + biographic data	LTO verification API
PRC ID	Professional Regulation Commission	License number + biographic data	PRC verification API
Voter's ID	COMELEC	Voter ID number + biographic data	COMELEC verification (if available)
Postal ID	Philippine Postal Corporation	Postal ID number + biographic data	PhilPost verification
National Bureau of Clearance ID	NBI	NBI ID number + biographic data	NBI verification API
PhilSys ID (physical card)	PSA	QR code scan	QR code verification (offline capable)

3.3.3 Verification Process

1. User or agent captures front and back photos of government ID
2. OCR extracts: document number, full name, date of birth, address, expiry date
3. Document authenticity checks: security features, hologram, microprint analysis
4. Liveness check: user captures selfie, compared to ID photo via facial recognition
5. Third-party document verification service validates document against issuing authority database
6. Manual review if automated verification fails or confidence is below threshold

3.3.4 Capability Limits

Parameter	Limit
Maximum daily transactions	10
Maximum daily transaction value	PHP 50,000
Maximum monthly transaction value	PHP 200,000
Maximum single transaction value	PHP 25,000
Voucher receipt	Allowed (all categories)
Cash-out	Self-service or agent-mediated
Cross-border payments	Not allowed
Credit access	Referral only (partner underwrites)
Sub-program enrollment	Allowed (standard programs)

3.3.5 Re-screening Requirements

• Annual AMLC/CFT screening required
• Document expiry monitoring: notify user 60 days before expiry
• Expired document: account downgraded to Tier 0 until new document provided

3.4 Tier 2: PhilSys-Linked

3.4.1 Overview

PhilSys Number provided with explicit consent. Identity verified through PhilSys Verification API. This is the recommended tier for all users who have registered for PhilSys, offering the best balance of user experience, verification confidence, and regulatory compliance.

3.4.2 Verification Requirements

• Valid PhilSys Number (12-digit format with check digit validation)
• Explicit consent captured per Section 2 of this specification
• Demographic data match via PhilSys Verification API
• PhilSys account status must be ACTIVE

3.4.3 Confidence Score Thresholds

Confidence Score	Match Status	Action	Timeline
85-100	MATCH	Auto-approve Tier 2	Immediate
60-84	PARTIAL_MATCH	Manual review by compliance officer	Within 48 hours
Below 60	NO_MATCH	Reject, offer alternative verification	Immediate
N/A	NOT_FOUND	PhilSys Number not found in system	Immediate, advise user to check number or register at PhilSys center
N/A	ERROR	System error, retry or escalate	Retry 3x, then manual review

3.4.4 Capability Limits

Parameter	Limit
Maximum daily transactions	25
Maximum daily transaction value	PHP 200,000
Maximum monthly transaction value	PHP 1,000,000
Maximum single transaction value	PHP 100,000
Voucher receipt	Allowed (all categories)
Cash-out	Self-service
Cross-border payments	Allowed (SEP-31, per program)
Credit access	Referral + pre-qualification (partner underwrites)
Sub-program enrollment	Allowed (all programs)

3.4.5 Re-screening Requirements

• Semi-annual AMLC/CFT screening required (every 6 months)
• PhilSys status check at each re-screening (verify account still ACTIVE)
• Significant change in transaction patterns triggers event-driven re-screening

3.5 Tier 3: Credit/Coop/SEC

3.5.1 Overview

Highest verification tier requiring all Tier 2 requirements plus additional identity and financial verification. Designed for users who need full platform capabilities including credit access, sub-program management, and enhanced transaction limits.

3.5.2 Additional Verification Requirements

Requirement	Source	Verification Method
Credit bureau report	Credit Information Corporation (CIC)	CIC-accredited credit bureau query
Cooperative membership	SEC-registered cooperative	Cooperative verification letter or API
TIN verification	Bureau of Internal Revenue (BIR)	TIN validation via BIR eReg system
Employer verification	Registered employer	Employment certificate or HR verification
DTI/SEC business registration	DTI or SEC	Business registration verification
Bank account verification	BSP-supervised bank	Bank account verification API or statement

Minimum requirements: PhilSys verification (Tier 2) + at least two (2) additional verification sources from the table above.

3.5.3 Capability Limits

Parameter	Limit
Maximum daily transactions	Program-specific (default: 50)
Maximum daily transaction value	Program-specific (default: PHP 500,000)
Maximum monthly transaction value	Program-specific (default: PHP 2,000,000)
Maximum single transaction value	Program-specific (default: PHP 250,000)
Voucher receipt	Allowed (all categories, program-specific limits)
Cash-out	Self-service
Cross-border payments	Full SEP-31 access
Credit access	Full referral credit access with preferential rates
Sub-program enrollment	Full access, eligible for sub-program management

3.5.4 Re-screening Requirements

• Quarterly AMLC/CFT screening required (every 3 months)
• Annual credit bureau re-check
• Continuous adverse media monitoring
• Transaction monitoring with enhanced due diligence (EDD) rules

3.6 Tier Comparison Matrix

Feature	Tier 0	Tier 1	Tier 2	Tier 3
Onboarding
Onboarding time	5-15 minutes	15-30 minutes	5-10 minutes (API)	1-3 business days
Agent required	Yes	Optional	No	No
Gov ID required	No	Yes	PhilSys only	PhilSys + additional
Consent required	Agent attestation	Standard KYC consent	PhilSys explicit consent	Comprehensive consent
Transaction Limits
Max daily transactions	3	10	25	50 (default)
Max daily value (PHP)	10,000	50,000	200,000	500,000 (default)
Max monthly value (PHP)	50,000	200,000	1,000,000	2,000,000 (default)
Max single transaction (PHP)	5,000	25,000	100,000	250,000 (default)
Capabilities
Voucher receipt	Restricted categories	All categories	All categories	All categories (program-specific)
Cash-out	Agent-mediated	Self or agent	Self-service	Self-service
Cross-border payments	No	No	Yes (SEP-31)	Full SEP-31
Credit access	No	Referral only	Referral + pre-qual	Full access
Sub-program management	Basic	Standard	All programs	Full management
Compliance
AML screening	Basic	Standard	Enhanced	Comprehensive (EDD)
Re-screening frequency	N/A	Annual	Semi-annual	Quarterly
Transaction monitoring	Basic rules	Standard rules	Enhanced rules	EDD rules

3.7 Tier Upgrade & Downgrade Rules

3.7.1 Upgrade Paths

Tier 0 ──► Tier 1 ──► Tier 2 ──► Tier 3
   │           │          │
   │           │          └──► Tier 3 (PhilSys + additional sources)
   │           └──────────────► Tier 2 (PhilSys)
   └──────────────────────────► Tier 1 (Government ID)

• Users may skip tiers if they meet requirements for higher tier directly
• Tier 0 users must upgrade to at least Tier 1 within 90 days or face account restrictions
• Upgrade is immediate upon verification completion (except Tier 3, which requires compliance officer approval)

3.7.2 Downgrade Triggers

Trigger	Action	Notice Period
Consent revoked	Downgrade to Tier 0	Immediate
Government ID expired	Downgrade to Tier 0	60-day grace period
PhilSys account status changed to INACTIVE/DECEASED	Downgrade to Tier 0	Immediate
AMLC hit confirmed	Account suspended	Immediate, compliance investigation
Fraud detected	Account suspended	Immediate, investigation
Tier 0 upgrade deadline (90 days) exceeded	Account restricted	30-day warning notice
Inactivity (12 months)	Account dormant	60-day warning notice

3.7.3 Tier Change Audit Trail

Every tier change is recorded in the Obligation Ledger:

{
  "event_type": "kyc_tier_changed",
  "user_id": "usr-001",
  "previous_tier": 0,
  "new_tier": 2,
  "reason": "philsys_verification_completed",
  "confidence_score": 95,
  "philsys_request_id": "PSA-REQ-20260407-000001",
  "approved_by": "system",
  "timestamp": "2026-04-07T09:30:10+08:00",
  "event_hash": "sha256:..."
}

---

4. MDM Golden Record Strategy

4.1 Single Authoritative Beneficiary Profile

The platform maintains a Master Data Management (MDM) Golden Record — a single authoritative beneficiary profile per PhilSys ID hash or program reference number. This golden record serves as the system-of-truth for all identity attributes across programs, agencies, and onboarding channels.

4.1.1 Golden Record Principles

• Single source of truth: Each beneficiary has exactly one golden record, regardless of how many programs, agencies, or channels they interact with
• PhilSys-anchored: When PhilSys verification is available, PhilSys data anchors the golden record
• Source-attributed: Every field in the golden record carries provenance metadata (source agency, timestamp, verification status)
• Conflict-resolved: When multiple sources provide conflicting data, override hierarchy rules resolve conflicts automatically
• Audit-complete: Every change to the golden record is logged with full lineage (previous value hash, new value hash, operator, timestamp)

4.1.2 Golden Record Identification

Identifier	Type	Purpose
golden_record_id	UUID v4	Internal primary key
philsys_hash	SHA-256 hash	Cross-program deduplication (PhilSys-verified users)
program_ref	String	Program-specific reference number
external_ids	Map	External system identifiers (BIR TIN, SSS, PhilHealth, etc.)

4.2 Cross-Agency Data Conflict Resolution

When multiple data sources provide conflicting information for the same beneficiary, the platform applies deterministic conflict resolution rules:

4.2.1 Conflict Resolution Rules

Conflict Scenario	Resolution Rule	Escalation	Logged
PhilSys vs. DA Program Registry	PhilSys data prevails	Auto-resolved, logged	Yes
PhilSys vs. LGU Records	PhilSys data prevails	Auto-resolved, logged	Yes
PhilSys vs. Agent Manual Input	PhilSys data prevails	Auto-resolved, logged	Yes
DA Program Registry vs. LGU Records	DA Program Registry prevails	Auto-resolved, logged	Yes
DA Program Registry vs. Agent Manual Input	DA Program Registry prevails	Auto-resolved, logged	Yes
LGU Records vs. Agent Manual Input	LGU Records prevail	Auto-resolved, logged	Yes
Conflicting PhilSys records (rare)	Most recent PhilSys API response prevails	Flagged for 48-hour human review	Yes
All sources disagree, no clear authority	Override hierarchy applied; unresolved fields flagged	48-hour human review queue	Yes
Temporal conflict (same source, different timestamps)	Most recent verified value prevails	Auto-resolved, logged	Yes

4.2.2 Override Hierarchy

┌─────────────────────────────────────────────────┐
│  PSA/PhilSys (highest authority)                │
│    ↓                                            │
│  DA Program Registry                            │
│    ↓                                            │
│  LGU Records                                    │
│    ↓                                            │
│  Agent Manual Input (lowest authority)          │
└─────────────────────────────────────────────────┘

• Higher tiers in the hierarchy auto-resolve conflicts in their favor
• Mismatches between sources at the same tier route to a 48-hour human review queue
• All conflict resolutions logged with: source agencies, conflicting values (hashed), resolution rule applied, timestamp, operator ID (for manual resolutions)
• Beneficiary notified of significant profile changes (name, DOB, address corrections) via preferred communication channel

4.2.3 Conflict Resolution Event Schema

{
  "event_type": "data_conflict_resolved",
  "golden_record_id": "uuid-v4",
  "field": "full_name",
  "conflicting_values": [
    {
      "value_hash": "sha256:abc...",
      "source_agency": "DA",
      "source_system": "DA-Registry-001",
      "timestamp": "2026-03-15T10:00:00+08:00"
    },
    {
      "value_hash": "sha256:def...",
      "source_agency": "PSA",
      "source_system": "PhilSys-API",
      "timestamp": "2026-04-07T09:30:06+08:00"
    }
  ],
  "resolution": {
    "rule": "philsys_prevails",
    "resolved_value_hash": "sha256:def...",
    "resolved_at": "2026-04-07T09:30:07+08:00",
    "resolved_by": "system"
  },
  "beneficiary_notified": true,
  "notification_channel": "sms",
  "event_hash": "sha256:..."
}

4.3 Golden Record Schema

{
  "golden_record_id": "550e8400-e29b-41d4-a716-446655440000",
  "philsys_hash": "sha256:8f3e4d5c6b7a8f9e0d1c2b3a4f5e6d7c8b9a0f1e2d3c4b5a6f7e8d9c0b1a2f3e",
  "program_ref": "AGRIFIN-2026-00001",
  "identity": {
    "full_name": {
      "value": "Juan Dela Cruz",
      "source": "philsys",
      "verified_at": "2026-04-07T09:30:06+08:00",
      "verification_method": "philsys_api_match"
    },
    "date_of_birth": {
      "value": "1990-01-15",
      "source": "philsys",
      "verified_at": "2026-04-07T09:30:06+08:00",
      "verification_method": "philsys_api_match"
    },
    "sex": {
      "value": "M",
      "source": "philsys",
      "verified_at": "2026-04-07T09:30:06+08:00"
    },
    "address": {
      "value": "123 Rizal St., Brgy. San Antonio, Makati City, 1203 Metro Manila",
      "source": "philsys",
      "verified_at": "2026-04-07T09:30:06+08:00",
      "verification_method": "philsys_api_match",
      "geocode": {
        "latitude": 14.5547,
        "longitude": 121.0244,
        "accuracy": "barangay"
      }
    },
    "phone": {
      "value": "+639171234567",
      "source": "agent",
      "verified_at": "2026-04-07T09:25:00+08:00",
      "verification_method": "sms_otp"
    },
    "email": {
      "value": null,
      "source": null,
      "verified_at": null
    }
  },
  "kyc_tier": 2,
  "kyc_tier_history": [
    {
      "tier": 0,
      "effective_from": "2026-04-07T09:25:00+08:00",
      "effective_to": "2026-04-07T09:30:10+08:00",
      "reason": "initial_agent_onboarding"
    },
    {
      "tier": 2,
      "effective_from": "2026-04-07T09:30:10+08:00",
      "effective_to": null,
      "reason": "philsys_verification_completed"
    }
  ],
  "aml_status": "clear",
  "aml_screening_history": [
    {
      "screened_at": "2026-04-07T09:30:15+08:00",
      "sources": ["UN_SC", "OFAC_SDN", "BSP_SANCTIONS", "PEP_DB"],
      "result": "clear",
      "next_screening_due": "2026-10-07T09:30:15+08:00"
    }
  ],
  "consent_records": [
    "550e8400-e29b-41d4-a716-446655440000"
  ],
  "external_ids": {
    "bir_tin": null,
    "sss_number": null,
    "philhealth_number": null
  },
  "data_lineage": [
    {
      "field": "full_name",
      "source_agency": "PSA",
      "timestamp": "2026-04-07T09:30:06+08:00",
      "operator_id": "system",
      "previous_value_hash": null,
      "new_value_hash": "sha256:abc123..."
    }
  ],
  "conflict_history": [],
  "created_at": "2026-04-07T09:25:00+08:00",
  "updated_at": "2026-04-07T09:30:10+08:00",
  "created_by": "agent-042",
  "updated_by": "system"
}

4.4 Duplicate Detection & Resolution

4.4.1 Duplicate Detection Strategies

Strategy	Method	Threshold
PhilSys hash match	Exact SHA-256 hash comparison	100% match = definite duplicate
Name + DOB + Barangay	Fuzzy name match (Levenshtein) + exact DOB + exact barangay	Name similarity >= 90% + DOB match + barangay match
Phone number match	Exact phone number match	100% match, flagged for review
Biometric (future)	Fingerprint/iris template comparison	PhilSys biometric matching

4.4.2 Duplicate Resolution Workflow

1. Duplicate detected during onboarding or data sync
2. System compares existing golden record(s) with new data
3. If PhilSys hash matches exactly: link to existing record, update with any new verified attributes
4. If probable duplicate (fuzzy match): flag for manual review in 48-hour queue
5. Manual review: compliance officer compares records, decides to merge or keep separate
6. Merge: all attributes reconciled per override hierarchy, merged record retains oldest creation date, all lineage preserved
7. Split: if records determined to be different individuals, both records marked with "not a duplicate" flag with reviewer notes

---

5. Data Lineage & Consent Management

5.1 Data Lineage Tracking

Every field change in the beneficiary golden record is tagged with complete provenance metadata:

5.1.1 Lineage Record Schema

{
  "lineage_id": "uuid-v4",
  "golden_record_id": "uuid-v4",
  "field": "identity.full_name",
  "previous_value_hash": "sha256:abc123...",
  "new_value_hash": "sha256:def456...",
  "source_agency": "PSA",
  "source_system": "PhilSys-API",
  "source_record_id": "PSA-REQ-20260407-000001",
  "timestamp": "2026-04-07T09:30:06+08:00",
  "operator_id": "system",
  "change_type": "create|update|override|correction|deletion",
  "change_reason": "philsys_verification_completed",
  "approval_required": false,
  "approved_by": null,
  "approved_at": null,
  "event_hash": "sha256:..."
}

5.1.2 Source Agency Codes

Code	Agency	Full Name	Data Authority
PSA	PSA	Philippine Statistics Authority	Highest (PhilSys anchor)
DA	DA	Department of Agriculture	Program-specific data
LGU	LGU	Local Government Unit	Barangay/municipality records
BIR	BIR	Bureau of Internal Revenue	TIN, tax records
SSS	SSS	Social Security System	SS number, employment
DFA	DFA	Department of Foreign Affairs	Passport data
LTO	LTO	Land Transportation Office	Driver's license data
AGENT	Agent	Platform-accredited agent	Agent-attested data
SYSTEM	System	Platform automated processes	System-generated data
USER	User	Self-declared by beneficiary	User-provided data

5.2 Cross-Agency Data Sharing Consent

When data is shared between government agencies (DA ↔ LGU ↔ PSA), the platform ensures DPA-compliant consent logging:

5.2.1 Data Sharing Event Schema

{
  "sharing_event_id": "uuid-v4",
  "golden_record_id": "uuid-v4",
  "data_subject_id": "usr-001",
  "disclosing_agency": "DA",
  "receiving_agency": "LGU",
  "data_categories_shared": [
    "identity_verification",
    "demographic_data",
    "program_participation"
  ],
  "purpose_code": "P004",
  "purpose_description": "Cross-agency coordination for program delivery",
  "legal_basis": "RA 10173 Section 12(f) - legitimate interest",
  "dpa_reference": "DPA-DA-LGU-2026-001",
  "data_subject_notified": true,
  "notification_channel": "sms",
  "notification_sent_at": "2026-04-07T09:30:20+08:00",
  "consent_reference": "550e8400-e29b-41d4-a716-446655440000",
  "timestamp": "2026-04-07T09:30:20+08:00"
}

5.2.2 Data Sharing Agreement Requirements

Per RA 10173 Section 41, data sharing between government agencies requires:

1. Executed Data Sharing Agreement (DSA) between agencies
2. DSA specifies: data categories, purpose, retention period, security measures, breach notification procedures
3. DSA reviewed and approved by DPO of both agencies
4. Data subject notified of data sharing (unless exempted by law)
5. Cross-border transfer restrictions apply if receiving agency stores data outside the Philippines

5.3 Automated DSR (Data Subject Rights) Handling Workflows

Under RA 10173 Chapter III, data subjects have the following rights:

5.3.1 DSR Workflow Matrix

Request Type	SLA	Automated Workflow	Manual Review Trigger	Escalation
Access (Sec. 16)	30 days	Identity verification → golden record extraction → secure delivery → audit log	Complex requests involving third-party data, large data volumes	DPO review
Rectification (Sec. 16)	30 days	Override hierarchy check → update golden record → MDM conflict resolution → confirmation to user → audit log	Conflict between agency sources, disputed corrections	DPO + source agency coordination
Erasure (Sec. 16)	30 days	Legal basis check → AMLA retention override check → secure deletion (NIST 800-88) → confirmation → audit log	AMLA 5-year retention active, legal hold, active investigation	DPO + legal review
Objection (Sec. 16)	30 days	Legal basis review → processing assessment → DPO decision → documentation → notification to user	Legitimate interest override required, system-wide impact	DPO + legal review
Portability (Sec. 18)	30 days	Golden record extraction → structured format (JSON/CSV) → secure delivery → audit log	Technical feasibility issues, third-party data inclusion	DPO + engineering review
Consent withdrawal (Sec. 12)	Immediate	Consent record update → processing cessation → impact assessment → tier downgrade if applicable → notification	AMLA legal basis continues processing, active program enrollment	DPO review
Damages (Sec. 16)	30 days	Incident documentation → damage assessment → compensation evaluation → legal review	Compensation dispute, liability determination	Legal + Board review

5.3.2 DSR Request Schema

{
  "dsr_id": "uuid-v4",
  "data_subject_id": "usr-001",
  "request_type": "access|rectification|erasure|objection|portability|consent_withdrawal|damages",
  "request_channel": "mobile_app|web_portal|agent_app|email|walk_in",
  "request_details": {
    "description": "string",
    "specific_fields": ["identity.full_name", "identity.address"],
    "supporting_documents": ["doc_id_1", "doc_id_2"]
  },
  "identity_verified": true,
  "identity_verification_method": "kyc_tier_check|additional_verification",
  "status": "received|processing|manual_review|completed|rejected",
  "assigned_to": "dpo-001",
  "sla_deadline": "2026-05-07T09:30:00+08:00",
  "completed_at": null,
  "outcome": null,
  "audit_trail": [
    {
      "action": "request_received",
      "timestamp": "2026-04-07T09:30:00+08:00",
      "actor": "system"
    }
  ]
}

5.4 Consent Analytics & Reporting

5.4.1 Consent Dashboard Metrics

Metric	Description	Alert Threshold
Total active consents	Count of non-revoked consents	N/A
Consent grant rate (daily)	New consents per day	>200% of 30-day average
Consent revocation rate	Percentage of consents revoked	>10% in 30-day period
Consent expiry rate	Consents expiring in next 30 days	>20% of active consents
Processing without valid consent	Active processing with expired/revoked consent	Any (zero tolerance)
Consent language distribution	Breakdown by language	N/A
Consent purpose distribution	Breakdown by purpose code	N/A

---

6. AMLC/CFT Screening Integration

6.1 Screening Sources

Source	Type	Update Frequency	Coverage	API Access	Legal Authority
UN Security Council Sanctions List	Sanctions	Real-time	Global	UN SC API	UN Security Council Resolutions
OFAC SDN List	Sanctions	Daily	US-designated persons/entities	OFAC API	US Executive Orders
EU Consolidated Sanctions List	Sanctions	Weekly	EU-designated persons/entities	EU API	EU Council Regulations
BSP Financial Sanctions List	Sanctions	As issued	Philippines	BSP circulars	BSP regulations
AMLC Terrorist Financing List	Terrorism	As issued	Philippines	AMLC advisories	RA 10168 (Terrorism Financing Act)
PEP Database (commercial provider)	PEP	Monthly	Global and domestic PEPs	Commercial API	FATF Recommendation 12
Adverse Media Screening	Adverse Media	Continuous	News, web sources	Commercial API	FATF risk-based approach
Interpol Notices	Law Enforcement	Daily	Global fugitives	Interpol API	Interpol Constitution

6.2 Screening Workflow

6.2.1 Screening Triggers

Trigger	Type	Screening Scope	Timing
Onboarding	Mandatory	Full (all sources)	Before account activation
Tier upgrade	Mandatory	Full (all sources)	Before tier change
Periodic re-screening (Tier 1)	Scheduled	Full (all sources)	Annual
Periodic re-screening (Tier 2)	Scheduled	Full (all sources)	Semi-annual
Periodic re-screening (Tier 3)	Scheduled	Full (all sources) + EDD	Quarterly
Transaction pattern change	Event-driven	Targeted (sanctions + adverse media)	Real-time monitoring
Geographic relocation	Event-driven	Targeted (sanctions + PEP)	Within 24 hours
KYC information update	Event-driven	Full (all sources)	Within 24 hours
Compliance flag raised	Event-driven	Full (all sources)	Immediate
Name change detected	Event-driven	Full (all sources)	Within 24 hours

6.2.2 Results Classification

Result	Description	Action	SLA
Clear	No matches found in any source	Proceed with onboarding/transaction	Immediate
Possible match	Name similarity match requiring human review	Hold account, escalate to compliance officer for manual review	48 hours
Confirmed match	Verified match against sanctions/PEP list	Block account, file STR/CTR with AMLC, notify BSP if required	Immediate block, STR within 5 working days
False positive	Match ruled out after review	Clear flag, document rationale, resume normal processing	48 hours

6.2.3 Screening Result Schema

{
  "screening_id": "uuid-v4",
  "golden_record_id": "uuid-v4",
  "user_id": "usr-001",
  "screening_type": "onboarding|periodic|event_triggered",
  "trigger": "string",
  "screened_at": "2026-04-07T09:30:15+08:00",
  "sources_checked": [
    "UN_SC",
    "OFAC_SDN",
    "EU_CONSOLIDATED",
    "BSP_SANCTIONS",
    "AMLC_TF",
    "PEP_DB",
    "ADVERSE_MEDIA",
    "INTERPOL"
  ],
  "results": {
    "overall_result": "clear|possible_match|confirmed_match",
    "sanctions_result": {
      "matched": false,
      "matches": []
    },
    "pep_result": {
      "matched": false,
      "matches": []
    },
    "adverse_media": {
      "flagged": false,
      "articles": []
    }
  },
  "risk_score": 15,
  "risk_level": "low|medium|high|critical",
  "next_screening_due": "2026-10-07T09:30:15+08:00",
  "reviewed_by": "system",
  "reviewed_at": "2026-04-07T09:30:16+08:00",
  "notes": null
}

6.3 Device & IP Profiling

6.3.1 Profiling Signals

Signal	Description	Data Source	Risk Indicator	Action
Device fingerprint	Unique device identifier generated from device attributes	Client-side SDK (FingerprintJS or equivalent)	New device = step-up authentication required	Require OTP + additional verification
IP geolocation	Geographic location derived from IP address	IP geolocation database (MaxMind or equivalent)	Mismatch with registered address >500km	Flag for review, require address confirmation
IP reputation	Known malicious IP databases	Threat intelligence feed (AbuseIPDB, Spamhaus)	Flagged IP = known malicious	Block request, alert security team
Login velocity	Number of logins from different IPs in time window	Platform access logs	>3 IPs in 24 hours	Flag for review, require step-up auth
Tor/VPN detection	Anonymization service detection	IP intelligence service	Tor/VPN detected	Require additional verification, may block
SIM swap detection	Mobile carrier SIM change notification	Telco API (Globe, Smart, DITO)	SIM swap within last 48 hours	48-hour hold on transactions, require in-person verification
Rooted/jailbroken device	Device integrity check	Client-side SDK (SafetyNet, DeviceCheck)	Compromised device detected	Block high-value transactions, require alternative channel
Emulator detection	Running in emulator/virtual environment	Client-side SDK	Emulator detected	Block onboarding, require physical device

6.3.2 Risk Scoring Model

Factor	Weight	Score Range
AMLC screening result	40%	0 (clear) to 100 (confirmed match)
Device risk signals	20%	0 (trusted device) to 100 (highly suspicious)
Geographic risk	15%	0 (low-risk area) to 100 (high-risk jurisdiction)
Transaction pattern risk	15%	0 (normal pattern) to 100 (highly anomalous)
KYC tier risk	10%	0 (Tier 3) to 100 (Tier 0)

Composite Risk Score: Weighted sum of all factors, range 0-100

Risk Level	Score Range	Action
Low	0-25	Normal processing
Medium	26-50	Enhanced monitoring, flag for periodic review
High	51-75	Enhanced due diligence, compliance officer review
Critical	76-100	Immediate block, STR filing, escalate to AMLC

6.4 STR/CTR Filing Integration

6.4.1 Suspicious Transaction Report (STR)

Per RA 9160 (AMLA) as amended by RA 10167 and RA 10365:

Requirement	Detail
Filing threshold	Any transaction (attempted or completed) that is unusual, complex, abnormally large, or has no lawful purpose
Filing deadline	Within 5 working days from occurrence (or 10 working days for complex cases)
Filing authority	AMLC (Anti-Money Laundering Council)
Cover	STR filers are protected from liability under RA 9160 Section 9
Prohibition	"Tipping off" — prohibited from informing the subject that an STR has been filed

6.4.2 Covered Transaction Report (CTR)

Requirement	Detail
Filing threshold	Cash transactions exceeding PHP 500,000 (or equivalent in other currencies) within 1 banking day
Filing deadline	Within 5 working days from occurrence
Filing authority	AMLC
Covered persons	As defined in RA 9160 Section 3(a) — includes financial institutions, money changers, remittance companies

6.4.3 STR/CTR Event Schema

{
  "report_id": "uuid-v4",
  "report_type": "STR|CTR",
  "golden_record_id": "uuid-v4",
  "user_id": "usr-001",
  "filing_date": "2026-04-12T17:00:00+08:00",
  "reporting_deadline": "2026-04-12T17:00:00+08:00",
  "trigger_event": "confirmed_amlc_match",
  "transaction_details": {
    "transaction_ids": ["txn-001", "txn-002"],
    "total_amount_php": 750000,
    "transaction_period": "2026-04-01 to 2026-04-07",
    "suspicious_indicators": ["abnormally_large", "rapid_movement", "high_risk_jurisdiction"]
  },
  "amlc_screening_result": {
    "screening_id": "scr-001",
    "matched_list": "OFAC_SDN",
    "match_confidence": 95,
    "matched_entity": "REDACTED"
  },
  "filed_by": "compliance-officer-001",
  "filed_with": "AMLC",
  "amlc_reference": null,
  "status": "draft|filed|acknowledged",
  "tipping_off_protected": true,
  "audit_hash": "sha256:..."
}

---

7. Fallback Onboarding Paths

7.1 Offline Queue Mode

For areas with no or intermittent connectivity (Geographically Isolated and Disadvantaged Areas — GIDAs):

7.1.1 Offline Capabilities

Capability	Tier 0	Tier 1	Tier 2	Tier 3
Demographic data capture	Yes	Yes	No (requires PhilSys API)	No
Photo capture	Yes	Yes	No	No
Geotag recording	Yes	Yes	No	No
Agent attestation	Yes	Yes	No	No
Government ID photo capture	N/A	Yes	No	No
Consent capture	Yes (stored locally)	Yes (stored locally)	No	No
AML pre-screening	No (requires connectivity)	No	No	No

7.1.2 Offline Data Storage

• Data stored encrypted on device using AES-256-GCM
• Encryption key derived from device-specific key + agent PIN (PBKDF2, 100,000 iterations)
• Data partitioned: consent records, demographic data, photos, attestations
• Maximum offline storage: 500 records per device (configurable)
• Auto-purge of oldest synced records when storage limit reached

7.1.3 Sync Queue Protocol

Parameter	Value	Rationale
Sync priority	Oldest records first (FIFO)	Ensures no record is left unsynced indefinitely
Maximum offline period	72 hours	After which app locks and requires sync
Sync trigger	Connectivity detected + manual sync + scheduled (every 4 hours if connected)	Balance between data freshness and bandwidth usage
Batch size	50 records per batch	Optimal for mobile bandwidth
Conflict resolution	Server-side validation, MDM golden record conflict detection, duplicate check via name+DOB+barangay hash	Ensures data integrity
Retry strategy	Exponential backoff (1 min, 5 min, 15 min, 1 hour)	Handles intermittent connectivity
Failed record handling	Flagged for manual review, retained in queue	No data loss

7.2 Agent-Mediated Verification

7.2.1 Agent Accreditation Requirements

Requirement	Detail	Verification
Background check	NBI Clearance, Police Clearance, Barangay Clearance	Document verification
Training certification	Platform KYC training course completion (minimum 8 hours)	Certificate issued, annual renewal
Bonding	Performance bond (amount set by platform policy)	Surety bond from accredited insurer
Identity verification	Tier 2 or Tier 3 KYC completed	Platform KYC verification
Device registration	Registered mobile device with platform MDM	Device enrollment, certificate installed
Geographic assignment	Assigned to specific barangay/municipality	Geographic database entry
Agreement signing	Agent Agreement signed (digital or paper)	Document stored, signature verified

7.2.2 Agent Performance Monitoring

Metric	Target	Alert Threshold	Action
Approval rate	80-95%	<70% or >99%	Review for fraud or over-cautiousness
Fraud rate	<1%	>3%	Investigation, possible de-accreditation
Complaints	0 per month	>2 per month	Review, possible retraining
Offline period utilization	<50% of time	>80% offline	Check for connectivity issues or misuse
Sync timeliness	Within 24 hours of data capture	>48 hours	Warning, possible suspension
Onboarding volume	5-20 per week	>50 per week	Review for quality vs. quantity

7.2.3 Conflict of Interest Prevention

• Agents cannot approve their own referrals — system enforces separation
• Agent cannot onboard family members (same surname + same barangay check) without supervisor approval
• Agent performance metrics reviewed monthly by compliance team
• Random audit of 5% of agent-onboarded accounts quarterly
• Fraudulent attestation results in: immediate de-accreditation, bond forfeiture, referral to law enforcement, permanent ban from platform

7.3 Deferred Sync Protocol

When connectivity is restored after an offline period:

Sequence: Deferred Sync Protocol

Agent Device          Platform API           MDM Service        Compliance
    │                      │                     │                  │
    │──(1) Authenticate───▶│                     │                  │
    │   (mTLS + device     │                     │                  │
    │    certificate)      │                     │                  │
    │                      │                     │                  │
    │◀──(2) Auth OK────────│                     │                  │
    │                      │                     │                  │
    │──(3) Upload batch───▶│                     │                  │
    │   (50 records)       │                     │                  │
    │                      │                     │                  │
    │                      │──(4) Validate ──────▶│                  │
    │                      │   each record        │                  │
    │                      │                     │                  │
    │                      │◀──(5) Validation ────│                  │
    │                      │   results            │                  │
    │                      │                     │                  │
    │                      │──(6) MDM conflict ──▶│                  │
    │                      │   detection          │                  │
    │                      │                     │                  │
    │                      │◀──(7) Conflict ──────│                  │
    │                      │   resolution         │                  │
    │                      │                     │                  │
    │                      │─────────────────────▶│──(8) Golden ─────│
    │                      │                     │    record update  │
    │                      │                     │                  │
    │◀──(9) Confirmation───│                     │                  │
    │   (per record)       │                     │                  │
    │                      │                     │                  │
    │                      │───────────────────────────────────────▶│──(10) Audit log
    │                      │                     │                  │     entries

7.3.1 Sync Steps Detail

1. Device authenticates to platform using mutual TLS + device certificate
2. Platform confirms authentication and provides sync session token
3. Queued records uploaded in batch (max 50 records per batch, oldest first)
4. Server validates each record: signature verification, data completeness, policy compliance
5. Validation results returned to server processing pipeline
6. MDM conflict detection: duplicate check via PhilSys hash or name+DOB+barangay hash, override hierarchy application
7. Conflict resolution applied per Section 4.2 rules
8. Golden record updated with new data, lineage recorded
9. Confirmation sent to device for each processed record (success, conflict, or failure)
10. Audit log entries created in Obligation Ledger for all processed records

7.3.2 Failed Record Handling

Failure Type	Cause	Handling
Signature verification failed	Data tampered or corrupted	Record flagged, agent notified, re-capture required
Duplicate detected	Same user onboarded twice	Linked to existing golden record, agent notified
Incomplete data	Required fields missing	Record flagged, agent notified to complete missing data
Policy violation	Agent not authorized for area, expired credentials	Record rejected, agent notified, compliance alerted
Server error	Platform-side issue	Record retained in device queue, retry on next sync

7.4 Low-Connectivity Area Designation

7.4.1 Classification Criteria

Criterion	Threshold	Data Source
No cellular signal	0 bars (all major carriers)	Carrier coverage maps, agent app telemetry
Average bandwidth	<1 Mbps	Speed test data from agent app
Signal reliability	<50% uptime (24-hour measurement)	Agent app connectivity logs
Geographic isolation	Island, mountainous, or >10km from nearest town	PSGA (Philippine Standard Geographic Code) database

7.4.2 Area Database

Low-connectivity areas maintained in platform geographic database:

{
  "area_id": "GIDA-001",
  "barangay_code": "012304005",
  "barangay_name": "San Isidro",
  "municipality": "Banaue",
  "province": "Ifugao",
  "region": "CAR",
  "classification": "low_connectivity",
  "connectivity_metrics": {
    "average_bandwidth_mbps": 0.3,
    "uptime_percentage": 35,
    "carrier_coverage": {
      "globe": "poor",
      "smart": "none",
      "dito": "none"
    }
  },
  "offline_onboarding_enabled": true,
  "max_offline_hours": 72,
  "last_surveyed": "2026-03-01T00:00:00+08:00"
}

---

8. Retention & Regulatory Export

8.1 Retention Schedule

Data Category	Retention Period	Legal Basis	Deletion Method	Responsible Party
KYC identity data (golden record)	5 years from account closure	AMLA RA 9160 Section 9	Secure erase (NIST SP 800-88 Purge)	Data Engineering
PhilSys verification results	5 years from verification date	PhilSys RA 11055, AMLA RA 9160	Secure erase (NIST SP 800-88 Purge)	KYC Service
Transaction records (Obligation Ledger)	5 years from transaction date	AMLA RA 9160, BSP Circular No. 1098	Secure erase (NIST SP 800-88 Purge)	Ledger Service
Consent records	Duration of processing + 3 years	DPA RA 10173 Section 12	Secure erase (NIST SP 800-88 Purge)	Consent Service
AMLC screening results	5 years from screening date	AMLA RA 9160	Secure erase (NIST SP 800-88 Purge)	Compliance Service
Audit logs (event-sourced)	7 years	BSP Circular No. 1098, DPA RA 10173	Append-only during retention, then archive	Audit Service
Data lineage records	5 years from last change	DPA RA 10173, AMLA RA 9160	Secure erase (NIST SP 800-88 Purge)	MDM Service
Device/IP profiling data	1 year from collection	DPA RA 10173 (proportionality principle)	Automatic purge	Security Service
Marketing data	Until consent revoked	DPA RA 10173 (consent-based)	Secure erase (NIST SP 800-88 Purge)	Marketing Service
STR/CTR filings	5 years from filing	AMLA RA 9160	Secure erase (NIST SP 800-88 Purge)	Compliance Service
Agent attestation records	5 years from attestation	AMLA RA 9160, Agent Agreement	Secure erase (NIST SP 800-88 Purge)	Agent Service
DSR request records	5 years from resolution	DPA RA 10173	Secure erase (NIST SP 800-88 Purge)	DPO Office

8.2 Automated Deletion Workflow

Lifecycle: Automated Data Deletion

┌──────────────┐     ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│  Retention   │────▶│  Legal Hold  │────▶│  DPO Review  │────▶│  Deletion    │
│  Expiry      │     │  Check       │     │              │     │  Execution   │
│  Detected    │     │              │     │              │     │              │
└──────────────┘     └──────────────┘     └──────────────┘     └──────────────┘
        │                    │                    │                    │
        │                    ▼                    ▼                    ▼
        │              Active hold?          30-day grace        NIST 800-88
        │              YES → Skip            period begins       Purge executed
        │              NO → Continue                                │
        │                                                           ▼
        │                                                     Deletion
        │                                                     confirmed
        │                                                     in audit log

8.2.1 Deletion Steps

1. Retention period expiry detected by lifecycle management system (daily scan)
2. Legal hold check: Active investigation? Active litigation? Regulatory hold? If any hold exists, deletion is suspended
3. If no legal hold: Deletion scheduled with 30-day grace period
4. DPO notified for review of scheduled deletions (monthly batch)
5. Deletion executed:
   • Database records: NIST SP 800-88 Purge (overwrite with random data, verify)
   • Backups: Overwritten at next backup cycle (or earlier if on-demand purge requested)
   • Files: Cryptographically shredded (3-pass overwrite: random, 0x00, random)
   • PhilSys raw API responses: Cryptographically shredded with KMS key destruction
6. Deletion confirmation logged in audit trail with record IDs (hashed), deletion method, operator (system), timestamp
7. Monthly deletion report generated for DPO review: counts by data category, any failures, exceptions

8.2.2 Legal Hold Schema

{
  "legal_hold_id": "uuid-v4",
  "golden_record_id": "uuid-v4",
  "hold_type": "investigation|litigation|regulatory",
  "hold_reason": "AMLC investigation - Case #2026-001",
  "requested_by": "compliance-officer-001",
  "requested_at": "2026-04-07T10:00:00+08:00",
  "expected_release_date": null,
  "data_categories_covered": [
    "kyc_identity_data",
    "philsys_verification",
    "transaction_records",
    "amlc_screening"
  ],
  "status": "active|released|expired",
  "released_at": null,
  "released_by": null
}

8.3 Regulator-Ready Export Formats

8.3.1 CSV Export

• UTF-8 encoding (RFC 3629)
• Standard CSV with header row (RFC 4180)
• Fields quoted when containing commas, quotes, or newlines
• File naming convention: {program_id}_{category}_{date_range}.csv
  • Example: AGRIFIN-2026_kyc_20260101-20260331.csv
• Accompanied by data dictionary document (CSV and PDF formats)
• Maximum file size: 500 MB per file (split into multiple files if exceeded)

CSV Data Dictionary Template:

Field Name	Type	Description	Example	Nullable	Sensitive
user_id	String	Platform user identifier	usr-001	No	No
kyc_tier	Integer	KYC verification tier (0-3)	2	No	No
full_name	String	Verified full name	Juan Dela Cruz	No	Yes
date_of_birth	Date	Verified date of birth (ISO-8601)	1990-01-15	No	Yes

8.3.2 JSON Export

• JSON Lines format (one JSON object per line), UTF-8 encoding
• Nested structures flattened where appropriate for tabular analysis
• File naming convention: {program_id}_{category}_{date_range}.jsonl
  • Example: AGRIFIN-2026_transactions_20260101-20260331.jsonl
• Accompanied by JSON Schema document (Draft 2020-12)
• Maximum file size: 500 MB per file

JSON Schema Template:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "KYC Record Export",
  "type": "object",
  "properties": {
    "user_id": { "type": "string", "pattern": "^usr-\\d+$" },
    "kyc_tier": { "type": "integer", "minimum": 0, "maximum": 3 },
    "identity": {
      "type": "object",
      "properties": {
        "full_name": { "type": "string" },
        "date_of_birth": { "type": "string", "format": "date" },
        "address": { "type": "string" }
      },
      "required": ["full_name", "date_of_birth"]
    },
    "aml_status": { "type": "string", "enum": ["clear", "flagged", "under_review"] },
    "created_at": { "type": "string", "format": "date-time" }
  },
  "required": ["user_id", "kyc_tier", "identity", "aml_status", "created_at"]
}

8.3.3 PDF Export

• Formatted report with executive summary, detailed data tables, digital signature
• Table of contents with clickable links
• PDF/A-2b format for long-term archival compliance
• File naming convention: {program_id}_{report_type}_{date_range}.pdf
  • Example: AGRIFIN-2026_compliance_report_2026Q1.pdf
• Digital signature applied using platform code-signing certificate

8.4 Export Request & Delivery

8.4.1 Export Workflow

1. Authorized user submits export request via API or dashboard
   • Request includes: data categories, date range, format (CSV/JSON/PDF), delivery method
2. Export queued with priority based on user role and data size
   • Priority: DPO/Compliance Officer (P0), Regulator request (P0), Administrator (P1), User self-service (P2)
3. Export generated in requested format
   • Large exports processed asynchronously (webhook notification when ready)
   • Small exports (<10 MB) available for immediate download
4. User notified when ready via webhook, email, or in-app notification
5. Download link valid for 7 days (configurable by platform policy)
6. Download access logged in audit trail: user ID, timestamp, IP, file accessed
7. Export file automatically deleted after expiry (cryptographic deletion)

8.4.2 Export Request Schema

{
  "export_id": "uuid-v4",
  "requested_by": "compliance-officer-001",
  "request_type": "regulatory|internal_audit|user_self_service|dpa_request",
  "data_categories": [
    "kyc_identity_data",
    "philsys_verification",
    "transaction_records",
    "amlc_screening",
    "consent_records"
  ],
  "date_range": {
    "from": "2026-01-01T00:00:00+08:00",
    "to": "2026-03-31T23:59:59+08:00"
  },
  "format": "csv|json|pdf",
  "filters": {
    "program_id": "AGRIFIN-2026",
    "kyc_tier": [1, 2, 3],
    "aml_status": ["clear"]
  },
  "delivery": {
    "method": "download_link|email|s3_bucket|api_webhook",
    "destination": "string"
  },
  "priority": "P0|P1|P2",
  "status": "queued|processing|ready|downloaded|expired|failed",
  "requested_at": "2026-04-07T10:00:00+08:00",
  "completed_at": null,
  "download_url": null,
  "download_url_expires_at": null,
  "file_size_bytes": null,
  "error": null
}

---

9. Cross-Border Transfer Restrictions

9.1 DPA Cross-Border Transfer Rules (RA 10173, Section 41)

Personal data may be transferred outside the Philippines only if at least one of the following conditions is met:

Condition	Description	Applicability
Adequacy finding	Recipient country has been determined by the NPC to have adequate data protection laws	Requires NPC determination; currently limited jurisdictions
Explicit consent	Data subject has given explicit consent to the specific cross-border transfer	Most common basis for platform operations
Contract performance	Transfer is necessary for the performance of a contract between the data subject and the personal information controller	Applies to service delivery
Legal claims	Transfer is necessary for the establishment, exercise, or defense of legal claims	Litigation scenarios
Vital interests	Transfer is necessary to protect the vital interests of the data subject or another person	Emergency scenarios
Legitimate interest	Transfer is necessary for legitimate interests that are not overridden by the data subject's rights	Requires legitimate interest assessment (LIA)

9.2 Platform Cross-Border Transfer Policy

Transfer Type	Permitted	Conditions	Approval Required
Stellar blockchain data	Yes	On-chain data is pseudonymous (public keys, transaction hashes, amounts, asset codes only); no personal data stored directly on-chain	DPO pre-approval of data model
Cloud infrastructure	Yes	Provider has Philippine data center presence OR Standard Contractual Clauses (SCCs) executed; encryption at rest with customer-managed keys	DPO + legal review
Anchor partner (Philippines)	Yes	Both parties Philippine-based; DPA-compliant Data Sharing Agreement executed	Standard contractual clause
Third-party screening provider	Conditional	Provider has adequate data protection measures; SCCs executed; explicit consent included in user consent form	DPO approval per provider
Foreign government request	Only with legal process	Mutual Legal Assistance Treaty (MLAT), court order, or letter rogatory; NPC notification required	Legal + DPO + Board approval
Cloud backup (offshore)	Conditional	Encrypted backup with keys held in Philippines; SCCs; provider has ISO 27001 certification	DPO + security review
Developer access to production data	No	Production data containing personal information must not be accessible from outside the Philippines	N/A (prohibited)

9.3 Cross-Border Transfer Assessment

9.3.1 Transfer Impact Assessment (TIA)

Before any cross-border transfer, a Transfer Impact Assessment must be conducted:

Assessment Factor	Questions	Documentation
Recipient country laws	Does the recipient country have laws allowing government access to personal data?	Country law analysis
Adequacy	Has the NPC made an adequacy finding for the recipient country?	NPC adequacy determination
Safeguards	What contractual and technical safeguards are in place?	SCCs, encryption, access controls
Enforceability	Can data subject rights be enforced in the recipient jurisdiction?	Legal opinion
Redress mechanisms	What remedies are available to data subjects if their data is misused?	Redress procedure documentation

9.3.2 Cross-Border Transfer Log

{
  "transfer_id": "uuid-v4",
  "golden_record_id": "uuid-v4",
  "data_subject_id": "usr-001",
  "transfer_type": "blockchain|cloud_infrastructure|screening_provider|legal_request",
  "recipient": {
    "entity": "Cloud Provider Inc.",
    "country": "Singapore",
    "adequacy_status": "no_npc_finding",
    "safeguards": ["SCCs", "AES-256-GCM encryption", "customer-managed KMS keys"]
  },
  "data_categories_transferred": [
    "identity_verification",
    "demographic_data"
  ],
  "legal_basis": "RA 10173 Section 41(b) - explicit consent",
  "consent_reference": "550e8400-e29b-41d4-a716-446655440000",
  "tia_reference": "TIA-2026-001",
  "transferred_at": "2026-04-07T09:30:20+08:00",
  "approved_by": "dpo-001",
  "approved_at": "2026-04-01T00:00:00+08:00"
}

9.4 Stellar-Specific Considerations

9.4.1 On-Chain Data Policy

The Stellar blockchain is a public, permissionless, globally distributed ledger. The following rules apply:

Rule	Description	Enforcement
No personal data on-chain	Transaction metadata must NOT contain personal data (name, address, ID numbers, PhilSys Number)	Platform validation before transaction submission
Pseudonymous only	Only Stellar public keys, transaction hashes, amounts, and asset codes stored on-chain	By design of Stellar protocol
No sensitive data in memos	Stellar transaction memos must not contain personal or sensitive information	Memo validation middleware
Off-chain linkage	Linking on-chain data to off-chain identity exists only in platform's Obligation Ledger (encrypted, access-controlled)	Platform architecture
Global distribution inherent	Cross-border transfer of on-chain data is inherent to blockchain; covered by user consent at onboarding	Consent form disclosure
Right to erasure limitation	On-chain data cannot be erased; platform ensures no erasable personal data is ever placed on-chain	By design

9.4.2 Memo Field Validation

All Stellar transactions submitted by the platform pass through memo validation:

• Memo type text: Only allowed for transaction reference IDs (UUID format), no personal data
• Memo type id: Only numeric IDs (internal reference numbers)
• Memo type hash: Transaction hash references
• Memo type return: Return payment references
• Prohibited content patterns: names, addresses, ID numbers, phone numbers, email addresses, PhilSys Numbers

Memo validation regex (allowlist):

^(txn-[a-f0-9-]{36}|ref-\d{1,20}|hash-[a-f0-9]{64})$

9.4.3 Data Flow Diagram

┌─────────────────────────────────────────────────────────────────────┐
│                         Platform Architecture                      │
│                                                                     │
│  ┌──────────────┐    ┌──────────────────┐    ┌──────────────────┐  │
│  │  Obligation  │    │  KYC Service     │    │  Payment Service │  │
│  │  Ledger      │    │  (PhilSys API)   │    │  (Stellar)       │  │
│  │              │    │                  │    │                  │  │
│  │  Golden      │◀──▶│  Verification    │    │  Transaction     │  │
│  │  Records     │    │  Results         │    │  Submission      │  │
│  │  (encrypted) │    │  (encrypted)     │    │  (no PII on-chain)│  │
│  └──────┬───────┘    └────────┬─────────┘    └────────┬─────────┘  │
│         │                      │                       │            │
│         │              ┌───────┴───────────────────────┤            │
│         │              │    Data Linkage (encrypted)   │            │
│         │              │    user_id ↔ stellar_pubkey   │            │
│         │              └───────────────────────────────┘            │
│         │                                                           │
│         ▼                                                           │
│  ┌──────────────┐                                                   │
│  │  Philippines  │   Data stored in Philippine data centers         │
│  │  Data Center  │   (or SCC-protected offshore with encryption)    │
│  └──────────────┘                                                   │
│                                                                     │
└─────────────────────────────────────────────────────────────────────┘
                              │
                              ▼
              ┌───────────────────────────────┐
              │   Stellar Network (Global)     │
              │   On-chain: pubkeys, txns,     │
              │   amounts, asset codes only    │
              │   NO personal data             │
              └───────────────────────────────┘

---

10. Incident Response & Breach Notification

10.1 Data Breach Classification

Severity	Classification	Criteria	Notification Timeline
Critical	Material breach affecting PhilSys data or identity records	PhilSys data exposed, identity data leaked, encryption keys compromised	NPC: 72 hours; Affected users: immediate
High	Breach affecting KYC data or transaction records	KYC data accessed by unauthorized party, transaction records exposed	NPC: 72 hours; Affected users: 7 days
Medium	Breach affecting non-sensitive data	Consent records exposed (without linked identity), audit logs accessed	NPC: 72 hours; Affected users: 30 days
Low	Minor incident with no data exposure	Attempted breach thwarted, internal policy violation	Internal report only

10.2 Breach Notification Requirements (RA 10173, Section 20)

Requirement	Detail
NPC notification	Within 72 hours from knowledge or reasonable belief of breach
Affected data subjects	As soon as reasonably practicable, including: nature of breach, data affected, measures taken, contact information for DPO
Content of notification	Nature of breach, categories of data subjects and records affected, likely consequences, measures taken or proposed to address the breach, measures to mitigate adverse effects, DPO contact information
Exemptions	Notification may be delayed if it would impede a criminal investigation (requires NPC approval)

10.3 Incident Response Workflow

Phase 1: Detection          Phase 2: Containment         Phase 3: Assessment
┌──────────────┐            ┌──────────────┐             ┌──────────────┐
│  Alert       │───────────▶│  Isolate     │────────────▶│  Assess      │
│  triggered   │            │  affected    │             │  scope and   │
│  by monitor  │            │  systems     │             │  severity    │
└──────────────┘            └──────────────┘             └──────────────┘
                                                                   │
                                                                   ▼
Phase 6: Post-Incident     Phase 5: Notification        Phase 4: Remediation
┌──────────────┐            ┌──────────────┐             ┌──────────────┐
│  Lessons     │◀───────────│  Notify NPC  │◀────────────│  Remediate   │
│  learned,    │            │  and affected│             │  vulnerability│
│  policy      │            │  data subjects│             │  Restore     │
│  updates     │            │  (per SLA)   │             │  systems     │
└──────────────┘            └──────────────┘             └──────────────┘

10.4 Incident Record Schema

{
  "incident_id": "INC-2026-001",
  "severity": "critical|high|medium|low",
  "incident_type": "data_breach|unauthorized_access|data_loss|system_compromise|policy_violation",
  "detected_at": "2026-04-07T14:30:00+08:00",
  "detected_by": "monitoring_system|user_report|audit|external_notification",
  "affected_systems": ["kyc-service", "obligation-ledger"],
  "affected_data_categories": ["kyc_identity_data", "philsys_verification"],
  "estimated_records_affected": 1500,
  "containment_actions": [
    {
      "action": "isolated_affected_instances",
      "timestamp": "2026-04-07T14:35:00+08:00",
      "actor": "security-team"
    }
  ],
  "assessment": {
    "root_cause": "string",
    "data_exfiltrated": true,
    "data_types_exposed": ["verified_name", "verified_dob", "verification_result"],
    "philsys_data_exposed": true
  },
  "notifications": {
    "npc_notified": true,
    "npc_notification_at": "2026-04-10T14:30:00+08:00",
    "npc_reference": "NPC-INC-2026-001",
    "users_notified": true,
    "user_notification_start": "2026-04-07T16:00:00+08:00",
    "user_notification_complete": "2026-04-08T18:00:00+08:00",
    "users_notified_count": 1500
  },
  "resolution": {
    "remediation_completed": true,
    "remediation_at": "2026-04-09T12:00:00+08:00",
    "systems_restored_at": "2026-04-10T08:00:00+08:00"
  },
  "post_incident": {
    "lessons_learned_completed": true,
    "lessons_learned_at": "2026-04-17T00:00:00+08:00",
    "policy_changes": ["enhanced_monitoring", "additional_encryption"],
    "follow_up_audit_scheduled": "2026-05-01T00:00:00+08:00"
  },
  "status": "detected|contained|assessed|remediated|notified|closed"
}

---

11. Testing & Quality Assurance

11.1 PhilSys API Integration Testing

11.1.1 Test Environments

Environment	Purpose	PhilSys Connectivity	Data
Local development	Unit testing, integration testing	Mock PhilSys API	Synthetic test data
Staging	Integration testing, UAT	PhilSys sandbox/test environment	Sanitized production data + synthetic data
Pre-production	Final validation before deployment	PhilSys production (test mode)	Production-like data
Production	Live operations	PhilSys production API	Live user data

11.1.2 Test Cases

Test ID	Test Scenario	Expected Result	Priority
PHI-001	Valid PhilSys Number with correct demographic data	MATCH with confidence >= 85	Critical
PHI-002	Valid PhilSys Number with incorrect name	PARTIAL_MATCH with confidence 60-84	Critical
PHI-003	Valid PhilSys Number with incorrect DOB	PARTIAL_MATCH or NO_MATCH	Critical
PHI-004	Invalid PhilSys Number format	Format validation error returned	Critical
PHI-005	PhilSys Number not found in PhilSys	NOT_FOUND returned	High
PHI-006	Deceased PhilSys account	DECEASED status returned	High
PHI-007	Duplicate PhilSys Number detection	Existing golden record linked	High
PHI-008	Consent not provided	Request rejected, consent required	Critical
PHI-009	Consent revoked	Request rejected, consent not valid	Critical
PHI-010	mTLS certificate rotation	Seamless transition, no downtime	High
PHI-011	OAuth token refresh	Token refreshed automatically, request retried	High
PHI-012	PhilSys API timeout	Retry with exponential backoff, async fallback	High
PHI-013	Rate limit handling	Queue request, retry after window	Medium
PHI-014	HMAC signature validation	Valid signature accepted, invalid rejected	Critical
PHI-015	Tier 2 auto-approval on MATCH >= 85	User upgraded to Tier 2 immediately	Critical
PHI-016	Manual review triggered on PARTIAL_MATCH	Record queued for compliance officer review	High
PHI-017	Rejection on NO_MATCH	User informed, alternative offered	High

11.1.3 Mock PhilSys API Response Generator

For local development and CI/CD testing, a mock PhilSys API is available:

{
  "mock_config": {
    "scenario": "MATCH|NO_MATCH|PARTIAL_MATCH|NOT_FOUND|ERROR|DECEASED",
    "confidence_score": 95,
    "processing_time_ms": 1250,
    "include_verified_attributes": true
  }
}

11.2 Performance Testing

Test	Target	Measurement
PhilSys API response time	<5 seconds (p95)	End-to-end from request submission to result
KYC tier upgrade processing	<2 seconds (p99)	From verification result receipt to tier update
Consent validation	<100 milliseconds (p99)	Consent record lookup and validation
Golden record update	<500 milliseconds (p99)	MDM update with lineage recording
AMLC screening	<30 seconds (p95)	Full screening across all sources
Offline sync (50 records)	<60 seconds	Complete batch upload and processing

11.3 Security Testing

Test	Frequency	Method	Standard
Penetration testing	Annual (minimum)	Third-party security firm	OWASP Top 10, PTES
PhilSys API security review	Semi-annual	Internal + external review	NIST SP 800-115
Encryption key rotation audit	Quarterly	Internal audit	NIST SP 800-57
Access control review	Monthly	Internal audit	RBAC policy
Vulnerability scanning	Weekly	Automated scanner (Nessus, Qualys)	CVE database
Dependency scanning	Continuous	Automated (Snyk, Dependabot)	Known vulnerability database
Configuration audit	Monthly	Automated (CIS benchmarks)	CIS Benchmarks

---

12. Glossary & Reference

12.1 Acronyms & Abbreviations

Acronym	Full Name	Description
PhilSys	Philippine Identification System	National ID system of the Philippines
PSA	Philippine Statistics Authority	Government agency administering PhilSys
DICT	Department of Information and Communications Technology	Government agency overseeing ICT
DPA	Data Privacy Act / Data Sharing Agreement	RA 10173 or Data Sharing Agreement (context-dependent)
NPC	National Privacy Commission	Philippine data protection authority
AMLC	Anti-Money Laundering Council	Philippine financial intelligence unit
AMLA	Anti-Money Laundering Act	RA 9160, as amended
CFT	Combatting the Financing of Terrorism	AML/CFT framework
BSP	Bangko Sentral ng Pilipinas	Philippine central bank
GSB	Government Service Bus	DICT-managed API gateway for government services
KYC	Know Your Customer	Identity verification process
MDM	Master Data Management	Golden record management system
PEP	Politically Exposed Person	Individual with prominent public function
STR	Suspicious Transaction Report	Filed with AMLC under RA 9160
CTR	Covered Transaction Report	Filed with AMLC for transactions > PHP 500,000
EDD	Enhanced Due Diligence	Additional verification for high-risk users
CIC	Credit Information Corporation	Philippine credit bureau
SEC	Securities and Exchange Commission	Philippine corporate regulator
BIR	Bureau of Internal Revenue	Philippine tax authority
GIDA	Geographically Isolated and Disadvantaged Area	Classification for remote areas
MFA	Multi-Factor Authentication	Authentication with multiple factors
OTP	One-Time Password	Single-use authentication code
PII	Personally Identifiable Information	Data that can identify an individual
RBAC	Role-Based Access Control	Access control by role
SCC	Standard Contractual Clauses	EU-approved cross-border data transfer clauses
TIA	Transfer Impact Assessment	Assessment of cross-border transfer risks
SEP-31	Stellar Ecosystem Proposal 31	Cross-border payment protocol
UMID	Unified Multi-Purpose ID	Philippine government ID (SSS/GSIS)
LTO	Land Transportation Office	Philippine driver's license issuer
DFA	Department of Foreign Affairs	Philippine passport issuer
PRC	Professional Regulation Commission	Philippine professional license issuer
COMELEC	Commission on Elections	Philippine voter registration authority
NBI	National Bureau of Investigation	Philippine law enforcement agency
TIN	Tax Identification Number	BIR-issued taxpayer identifier
RA	Republic Act	Philippine legislation
IRR	Implementing Rules and Regulations	Rules implementing a law

12.2 Regulatory Reference Index

Regulation	Full Citation	Key Sections
RA 11055	Philippine Identification System Act	Sec. 23 (Relying Party obligations), Sec. 24 (Prohibited acts)
RA 10173	Data Privacy Act of 2012	Sec. 12 (Lawful processing), Sec. 16 (Data subject rights), Sec. 20 (Breach notification), Sec. 41 (Cross-border transfer)
RA 9160	Anti-Money Laundering Act of 2001	Sec. 3 (Covered persons), Sec. 9 (Reporting requirements), Sec. 10 (Safe harbor)
RA 10167	AMLA Amendment (2012)	Expanded coverage to include insurance, mutual funds, pre-need companies
RA 10365	AMLA Amendment (2013)	Terrorism financing provisions
RA 10168	Terrorism Financing Prevention Act of 2012	Sec. 4 (Terrorist financing offenses)
RA 10175	Cybercrime Prevention Act of 2012	Sec. 4 (Cybercrime offenses)
BSP Circular No. 1098	Regulations on Electronic Money Issuers	Licensing, prudential requirements, consumer protection
NPC Circular No. 16-03	Security Measures for Personal Data Processing	Organizational, physical, technical security measures
NPC Advisory No. 2024-01	Guidelines on PhilSys Data Processing	NPC guidance on PhilSys compliance
FATF Recommendations	Financial Action Task Force Recommendations	Rec. 10 (CDD), Rec. 12 (PEPs)
NIST SP 800-88	Guidelines for Media Sanitization	Secure deletion standards
NIST SP 800-57	Recommendation for Key Management	Cryptographic key management

12.3 Version History

Version	Date	Author	Changes
1.0	2026-04-07	Platform Engineering	Initial release

---

📝 License

Proprietary - Bull Run Consulting / Starting Block Ventures

👥 Team

• Bull Run Consulting - Web3 venture builder
• Starting Block Ventures - Venture studio

🆘 Support

For issues or questions, contact the development team.