Skip to content

03_TREASURY_RESERVE_ATTESTATION_PLAYBOOK.md

Latest commit

 

History

History
1068 lines (846 loc) · 53.9 KB

03_TREASURY_RESERVE_ATTESTATION_PLAYBOOK.md

File metadata and controls

1068 lines (846 loc) · 53.9 KB

Treasury & Reserve Attestation Playbook

1. Reserve Model Overview

1.1 1:1 PHP Float Backing Principle

  • Every on-chain PHP-pegged token is backed 1:1 by PHP held in a segregated trust account at a BSP-supervised institution.
  • No fractional reserve, no rehypothecation, no investment of reserve funds in instruments that introduce counterparty risk.
  • Reserve funds held in demand deposit account (non-interest-bearing to avoid counterparty exposure).
  • Legal segregation language: "All funds held in the Reserve Account are the exclusive property of [Program] Beneficiaries and shall not form part of the Anchor's general assets, shall not be available to satisfy claims of the Anchor's creditors, and shall not be used for any purpose other than fulfilling payment obligations to Beneficiaries."
  • Prohibited instruments: Treasury bills, commercial paper, money market funds, repurchase agreements, structured notes, or any instrument with maturity > 0 days or principal risk.
  • Permitted instruments: Demand deposits only — zero maturity, zero market risk, immediately withdrawable.
  • Jurisdictional constraint: All reserve accounts domiciled in the Philippines under BSP jurisdiction; no offshore reserve holdings.
  • Currency constraint: Reserve held exclusively in PHP; no FX conversion risk on reserve side.

1.2 Segregated Trust Account Structure

Parameter Specification
Account type Trust / Demand Deposit Account
Institution BSP-supervised bank or Electronic Money Issuer (EMI)
Account title [Anchor Name] as Trustee for [Program Name] Beneficiaries
Signatories Dual: anchor treasury officer + platform treasury representative
Withdrawal restrictions Beneficiary payment obligations or program-authorized transfers only
Reporting Daily automated balance feed to platform Reconciliation Control Tower
Audit access Monthly internal attestation, quarterly external audit, annual comprehensive
Legal framework BSP Circular No. 1115 (Regulation of Virtual Asset Service Providers), RA 11765 (Financial Products and Services Consumer Protection Act)
Trust agreement Executed between Anchor and Program Administrator; registered with BSP
Account opening Requires BSP notification; trust deed filed with Securities and Exchange Commission (SEC) if structured as trust corporation
Insurance Philippine Deposit Insurance Corporation (PDIC) coverage up to PHP 500,000 per depositor (supplemental; primary protection is trust segregation)
Account closure Requires 90-day notice to BSP; all beneficiaries paid out before closure
Dormancy handling If no activity for 12 months, dormant account procedures per BSP Circular No. 464 apply

1.3 Multi-Anchor Distribution

Parameter Limit Rationale
Maximum exposure per anchor 40% of total reserve Diversification, single-anchor failure impact
Minimum number of anchors 2 (MVP), 3+ (Scale phase) Redundancy, failover capability
Anchor rebalancing frequency Monthly or upon breach Maintain exposure limits
Emergency concentration limit 60% single anchor (temporary, max 72 hours) During failover transition
Cross-anchor correlated exposure 60% combined maximum Prevent correlated failure
Anchor onboarding requirements BSP license, minimum capital PHP 2B, SLA compliance history >=99.9%, independent audit capability Quality gate
Anchor offboarding 30-day notice, reserve transfer within 5 business days, final attestation Controlled exit
Anchor performance review Quarterly scorecard (settlement SLA, error rate, uptime, compliance incidents) Continuous monitoring

1.4 Anchor Onboarding & Due Diligence

Before an anchor is approved to hold reserve funds, the following due diligence process must be completed:

  1. Regulatory verification: Confirm BSP license is active and in good standing; check AMLC registration; verify no pending enforcement actions.
  2. Financial health assessment: Review audited financial statements (last 2 years); confirm capital adequacy ratio meets BSP minimums; assess credit rating if available.
  3. Operational readiness: Verify API integration capability for automated balance reporting; confirm SLA terms match platform requirements; test failover procedures.
  4. Legal review: Execute trust agreement with segregation language; confirm account title format; establish signatory arrangements; define withdrawal procedures.
  5. Technical integration: Complete API connectivity testing; establish encrypted communication channels; verify data format compatibility (ISO 20022 or equivalent).
  6. Approval workflow: Treasury Committee review and vote (unanimous required for first anchor, majority for subsequent); Board notification.

1.5 Anchor Offboarding Procedure

When an anchor must be removed from the reserve distribution:

  1. Trigger identification: Anchor license revoked, SLA breach (3+ incidents in 30 days), voluntary withdrawal, or Treasury Committee decision.
  2. Notification: Written notice to anchor (30-day minimum); simultaneous BSP notification.
  3. Freeze period: No new issuance to anchor; existing obligations honored; settlement continues.
  4. Reserve transfer: Gradual transfer of reserve balance to remaining anchors over 5 business days; daily reconciliation during transfer.
  5. Final attestation: Independent verification that all funds transferred; Obligation Ledger updated to reflect new anchor distribution.
  6. Account closure confirmation: Written confirmation from anchor that trust account is closed; BSP notified of closure.

2. Daily NAV Reconciliation Workflow

2.1 NAV Calculation

NAV Ratio = Total Off-Chain Reserve Balance / Total On-Chain PHP Token Supply

Parameter Value
Target NAV Ratio 1.0000
Acceptable variance +/- 0.01%
Warning threshold +/- 0.005%
Alert threshold +/- 0.010%
Critical threshold +/- 0.050%
Emergency threshold +/- 0.100%
Calculation frequency Daily at 00:05 PHT (automated)
Data sources Anchor bank API (00:00), Horizon API (00:01), Obligation Ledger (00:01)
Rounding precision 4 decimal places
Time zone Philippine Time (PHT, UTC+8)

2.2 Three-Way Reconciliation Components

Component Source Update Frequency Responsibility Retention Format
Off-Chain Bank Float Anchor trust account balance via API Daily (00:00 PHT automated) Anchor system 10 years ISO 20022 camt.053
On-Chain Stellar Supply Horizon /assets endpoint — total PHP-pegged token supply Daily (00:01 PHT automated) Horizon indexer / Platform Permanent (immutable) JSON
Obligation Ledger Platform's append-only system-of-record — sum of all non-CLOSED obligations + settled history Real-time (per transaction) Platform Reconciliation Control Tower Permanent (immutable) JSON with Merkle root

2.3 Reconciliation Schedule

Step Activity Time Responsible System SLA
1 Anchor bank balance snapshot 00:00 PHT (auto) Anchor system Bank API (HTTPS + mTLS) <5 seconds
2 On-chain supply snapshot 00:01 PHT (auto) Horizon indexer Stellar Horizon <5 seconds
3 Obligation Ledger snapshot 00:01 PHT (auto) Platform ledger Internal DB (PostgreSQL) <2 seconds
4 Three-way match computation 00:05 PHT (auto) Reconciliation engine Platform microservice <30 seconds
5 Variance analysis & classification 00:10 PHT (auto) Reconciliation engine Platform microservice <30 seconds
6 NAV report generation 00:15 PHT (auto) Reconciliation engine Platform microservice <15 seconds
7 Treasury review (if variance >0.005%) 08:00 PHT Treasury analyst Dashboard Within 2 hours
8 Maker-checker approval (if variance >0.01%) 09:00 PHT Treasury manager + CTO Approval workflow Within 4 hours
9 Regulatory notification (if variance >0.05%) 10:00 PHT Compliance officer BSP/AMLC portal Within 6 hours
10 Public attestation publication (monthly) 15th of month External auditor Website Within 15 business days

2.4 Variance Classification & Response

Variance Range Classification Automated Response Human Response Escalation Timeline
0.000% – 0.005% Normal Log and continue None N/A
0.005% – 0.010% Watch Increase monitoring frequency to hourly Treasury analyst review Within 4 hours
0.010% – 0.050% Alert Halt new issuances, open investigation queue Maker-checker investigation, compensation approval Within 2 hours
0.050% – 0.100% Critical Halt all operations, notify BSP Emergency treasury committee, external auditor engagement Within 1 hour
>0.100% Emergency Full halt, regulatory notification, public disclosure Board-level response, Emergency Settlement Protocol activation Immediate

2.5 Obligation Ledger Reconciliation Workflow

The Obligation Ledger is the binding third leg of NAV reconciliation. Every obligation entry must map to either:

  • A confirmed on-chain Stellar transaction (SETTLED_ONCHAIN status), OR
  • A confirmed anchor fiat settlement (CONFIRMED_FIAT status), OR
  • An authorized manual payout under Emergency Settlement Protocol (CLOSED with emergency_reconciliation_ref)

Reconciliation matching rules:

  1. Each Obligation Ledger entry with status SETTLED_ONCHAIN must have a valid stellar_tx_hash matching a Horizon-confirmed transaction.
  2. Each entry with status CONFIRMED_FIAT must have a settlement_ref matching an anchor settlement log entry.
  3. Sum of all non-CLOSED obligations must equal the on-chain PHP token supply.
  4. Sum of all CLOSED obligations (historical) must equal the cumulative fiat settled in anchor accounts.
  5. Any unmatched entry triggers an investigation case with auto-generated case ID (INV-{YYYYMMDD}-{sequence}).
  6. Each Obligation Ledger entry includes a program_ref linking it to a specific voucher/disbursement program.
  7. Obligation Ledger entries are immutable once written; corrections are new entries with correction_of reference to original entry.
  8. Daily Merkle root of Obligation Ledger is computed and stored on-chain (Stellar memo field or separate anchoring service) for tamper-proof verification.

2.6 Investigation Queue Workflow

When variance exceeds 0.01%:

  1. Automated investigation opened with unique case ID (INV-{YYYYMMDD}-{sequence}).
  2. System performs automated root cause analysis:
    • a. Check for pending/unconfirmed Stellar transactions (network delay, underfunded source account).
    • b. Check for bank settlement delays (T+1 lag, PESONet cut-off time missed).
    • c. Check for duplicate or missing Obligation Ledger entries (double-spend, missed issuance).
    • d. Check for fee accrual discrepancies (Stellar base fee, anchor spread).
    • e. Check for anchor reporting errors (API response mismatch, stale data).
    • f. Check for emergency manual payouts not yet reconciled.
    • g. Check for rounding/precision errors in NAV computation.
    • h. Check for time zone mismatches between data sources.
  3. Investigation results queued for maker-checker review with all diagnostic data attached.
  4. Maker (Treasury Analyst) proposes compensation adjustment with supporting evidence.
  5. Checker (Treasury Manager or CTO) approves or rejects based on approval matrix.
  6. Approved adjustments executed with full audit trail (timestamp, operator, rationale).
  7. Case closed with documented root cause and resolution; summary added to monthly attestation.

Investigation case lifecycle:

OPENED → ROOT_CAUSE_ANALYSIS → PENDING_REVIEW → APPROVED/REJECTED → EXECUTED → CLOSED

SLA for investigation cases:

Priority Initial Response Root Cause Analysis Resolution
P1 (Emergency, >0.100%) 15 minutes 1 hour 4 hours
P2 (Critical, 0.050–0.100%) 30 minutes 2 hours 8 hours
P3 (Alert, 0.010–0.050%) 1 hour 4 hours 24 hours
P4 (Watch, 0.005–0.010%) 4 hours 8 hours 48 hours

2.7 Maker-Checker Compensation Approval

Operation Maker Role Checker Role Approval Threshold Audit Requirement
NAV adjustment < PHP 10,000 Treasury Analyst Treasury Manager Single checker Logged
NAV adjustment PHP 10K–100K Treasury Analyst Treasury Manager + CTO Dual checker Logged + flagged
NAV adjustment > PHP 100,000 Treasury Manager CTO + CFO Dual executive Logged + Board notification
Reserve transfer Treasury Manager CTO + CFO + Anchor signatory Triple signatory Logged + external audit
Clawback execution Compliance Officer CTO + Legal Dual executive + legal Logged + regulatory notice
Emergency manual payout Treasury Manager CTO (dual-control) Dual-control Logged + BSP notification within 2h

Maker-Checker principles:

  • Maker and Checker must be different individuals (no self-approval).
  • Maker and Checker must have distinct system roles (enforced by RBAC).
  • All approvals cryptographically signed (Ed25519 private key) and timestamped.
  • Rejected proposals returned to Maker with written justification.
  • All proposals and approvals stored in immutable audit log (append-only, 10-year retention).
  • Timeout: Unchecked proposals auto-escalate after 4 hours to next-level approver.

3. Emergency Settlement Governance

3.1 Treasury Emergency Protocol Activation Criteria

The Treasury Emergency Protocol (TEP) is activated when any of the following conditions are met:

Trigger Threshold Activation Authority Notification Required
NAV variance >0.01% sustained for 2 consecutive reconciliation cycles Treasury Manager BSP within 2 hours
Anchor failure Primary anchor unresponsive for >4 hours Treasury Manager + CTO BSP within 2 hours
Stellar network degradation No settlement possible for >30 minutes CTO BSP within 4 hours
Reserve shortfall Bank balance < on-chain supply Treasury Manager + CTO + CFO BSP within 1 hour
Regulatory directive BSP/AMLC order Compliance Officer Acknowledge immediately
Fraud confirmation Confirmed fraudulent activity affecting reserve Compliance Officer + CTO BSP/AMLC within 1 hour
Cybersecurity incident Confirmed breach of treasury systems CTO + CFO BSP/DPA within 72 hours
Natural disaster Force majeure affecting anchor or platform operations CTO + CFO BSP within 4 hours

3.2 Emergency Protocol Procedures

Step Action Timeline Authorization Verification
1 TEP declared Immediate (T+0) Treasury Manager Logged with timestamp
2 Obligation Ledger frozen for new non-emergency entries Immediate System automated Verified by system health check
3 BSP/AMLC notification Within 2 hours Compliance Officer Delivery confirmation
4 PESONet/InstaPay batch file generation for manual payouts Within 4 hours Treasury Manager + CTO (dual-control) Dual signature on batch file
5 Each manual payout cryptographically bound to signed Obligation Ledger entry Per transaction Maker-Checker (dual-control) Binding hash verified
6 Regulator-reportable audit trail compiled Within 24 hours Compliance Officer BSP submission confirmed
7 Manual override time-bound: maximum 72 hours 72 hours from activation CTO + CFO + Board notification Automatic expiry
8 Post-emergency full reconciliation Within 5 business days External auditor review Clean reconciliation confirmed
9 Post-mortem report Within 10 business days Treasury Committee Board presentation
10 Remediation plan implementation Within 30 business days Treasury Committee + Board Tracked to closure

3.3 Dual-Control Authorization for Emergency Payouts

All emergency manual payouts require:

  • Maker: Treasury Manager proposes payout with signed Obligation Ledger reference (obligation_id, amount, beneficiary_hash, program_ref).
  • Checker: CTO or CFO independently verifies and approves.
  • Both authorizations cryptographically signed (Ed25519) and recorded in immutable audit log.
  • Manual payout linked to Obligation Ledger entry via reconciliation_ref field.
  • Payout amount deducted from anchor reserve account via PESONet/InstaPay batch file.
  • Post-payout: Obligation Ledger entry transitioned to CLOSED with emergency_settlement flag.

Payout processing workflow:

1. Treasury Manager creates payout proposal → signed with private key
2. System validates proposal against Obligation Ledger (amount, beneficiary, program)
3. CTO/CFO receives notification → reviews → approves/rejects → signed with private key
4. If approved: batch file generated → transmitted to anchor bank via secure channel
5. Anchor confirms execution → settlement_ref recorded
6. Obligation Ledger updated → CLOSED with emergency_settlement flag
7. Daily reconciliation includes emergency payout verification

3.4 Cryptographic Binding of Manual Payouts

Each emergency manual payout is cryptographically bound to the Obligation Ledger:

{
  "obligation_id": "uuid",
  "pesonet_ref": "string",
  "amount": "decimal",
  "beneficiary_hash": "sha256",
  "program_ref": "string",
  "timestamp": "ISO-8601",
  "maker_signature": "ed25519",
  "checker_signature": "ed25519"
}
binding_hash = SHA-256(canonical_json(payload))

The binding_hash is recorded in both the Obligation Ledger and the separate emergency audit channel (10-year retention).

Canonical JSON rules:

  • Keys sorted alphabetically (lexicographic order).
  • No whitespace outside string values.
  • All strings UTF-8 encoded.
  • Numbers serialized as strings to preserve decimal precision.
  • Boolean values lowercase (true/false).
  • Null values serialized as null.

Verification process:

  1. Retrieve payout record from Obligation Ledger.
  2. Reconstruct canonical JSON from stored fields.
  3. Compute SHA-256 hash.
  4. Compare to stored binding_hash.
  5. Verify both Ed25519 signatures against known public keys of authorized signatories.
  6. Cross-reference pesonet_ref with anchor settlement log.
  7. Confirm amount matches Obligation Ledger entry.

3.5 Emergency Communication Protocol

Stakeholder Notification Method Timeline Content
BSP Secure portal + email Within 2 hours TEP activation notice, trigger, estimated impact
AMLC Secure portal + email Within 2 hours If fraud-related: incident details, affected accounts
DPA Secure email Within 72 hours If personal data breach involved
Anchor bank Secure API + phone Immediate Settlement halt/resume instructions
Beneficiaries In-app notification + SMS Within 24 hours Service disruption notice, expected resolution
Board of Directors Phone call + written brief Within 4 hours Executive summary, action plan
Public Website notice Within 24 hours High-level disclosure (no operational details)
External auditor Email + secure file transfer Within 4 hours Engagement for post-emergency review

4. Circuit Breaker Framework

4.1 Circuit Breaker Levels

Level Utilization Threshold Actions Recovery Requirement
Green (0–70%) Normal operations No restrictions N/A
Yellow (70–85%) Liquidity below 70% of required Enhanced monitoring, halt new issuances, notify treasury team Restore to >85%
Orange (85–95%) Liquidity below 85% stress threshold Halt all disbursements, emergency anchor funding request, BSP notification Restore to >95% with external funding
Red (>95%) Critical reserve depletion Full halt, regulatory notification, public disclosure, board emergency session External capital injection, program suspension

Note: Percentages refer to stress-tested liquidity coverage ratio, not NAV variance.

Liquidity Coverage Ratio (LCR) = Liquid Reserve Assets / Stress-Tested Net Cash Outflows (30-day horizon)

4.2 Exposure Limits Per Anchor

Metric Limit Monitoring Frequency Breach Response
Single anchor reserve share 40% of total Daily Rebalance within 5 business days
Single anchor daily settlement volume 25% of daily cap Per transaction Route to alternate anchor
Single anchor outstanding liabilities 35% of total Daily Suspend new issuances to anchor
Cross-anchor correlated exposure 60% combined Daily Diversify to 3rd anchor
Single anchor settlement latency >500ms p99 Per transaction Performance review, potential offboarding
Single anchor error rate >0.1% of transactions Daily Investigation, potential offboarding

4.3 Circuit Breaker Automation

  • Real-time monitoring of liquidity coverage ratio via Anchor SLA Monitoring Dashboard.
  • Automated alert at each threshold breach (PagerDuty/Opsgenie integration).
  • Automatic enforcement of restrictions (Green → Yellow transition requires no manual intervention).
  • Manual override requires maker-checker approval at Orange+ levels.
  • All circuit breaker events logged immutably with timestamp, trigger metric, and action taken.
  • Circuit breaker state machine:
GREEN ──LCR <70%──▶ YELLOW ──LCR <85%──▶ ORANGE ──LCR <95%──▶ RED
  ◀──LCR >85%───      ◀──LCR >70%───      ◀──LCR >85%───      ◀──LCR >95%───

Automatic actions per level:

Level Automated Actions
Green None — normal operations
Yellow Halt new issuances; increase reconciliation frequency to hourly; notify treasury team via PagerDuty
Orange Halt all disbursements; send emergency funding request to anchors; notify BSP; freeze circuit breaker at Orange until manual override
Red Full operational halt; notify BSP/AMLC; generate public disclosure draft; notify Board via automated call

4.4 Circuit Breaker Override Procedure

In exceptional circumstances, authorized personnel may override circuit breaker restrictions:

Override Level Authorization Duration Justification Required
Yellow override Treasury Manager Max 24 hours Written justification, recovery plan
Orange override CTO + CFO Max 48 hours Board notification, detailed recovery plan
Red override Board resolution Max 72 hours Regulatory notification, public disclosure

All overrides logged with full audit trail and automatically reported to BSP.

5. Stress Testing Scenarios

5.1 Stress Test Catalog

Scenario Description Parameters Expected Response Recovery Target
ST-01: Mass Withdrawal Simultaneous redemption by 30%+ of beneficiaries 30% of outstanding tokens redeemed within 24 hours Liquidity buffer absorbs, anchor T+0 funding activated Full restoration within 48 hours
ST-02: Anchor Delay Primary anchor fails to confirm settlements 0 confirmations from primary anchor for 4+ hours Automatic failover to secondary anchor Full service restoration within 2 hours of failover
ST-03: Bank Settlement Lag Anchor bank delays reserve reporting or transfers T+2 or T+3 settlement instead of T+1 Temporary buffer drawdown, stakeholder communication Normal settlement within 1 business day
ST-04: Fraud Spike Coordinated fraudulent transactions detected 5x normal fraud rate over 48 hours Transaction holds enhanced, vendor review, AMLC notification Fraud rate normalized, controls tightened
ST-05: Liquidity Buffer Recalculation Market conditions require higher buffer Buffer requirement increases from 15% to 25% Anchor funding request, disbursement throttling New buffer level achieved within 24 hours
ST-06: Stellar Network Degradation Stellar consensus delayed or Horizon API unavailable Transaction confirmation >60 seconds for >30 minutes Fallback Mode: async Kafka queuing, deferred settlement Normal operations upon Stellar recovery
ST-07: Multi-Anchor Failure 2+ anchors simultaneously degraded Combined anchor capacity below 50% Emergency halt, BSP notification, TEP activation Phased restoration as anchors recover
ST-08: Reserve Attestation Failure External auditor cannot confirm reserve Attestation report delayed or qualified Internal audit escalation, alternative auditor, BSP notification Clean attestation within 10 business days

5.2 Stress Testing Schedule

Test Frequency Scope Participants Reporting
Individual scenario test Quarterly One scenario per quarter Treasury, engineering Internal report
Full stress test suite Annually All 8 scenarios Treasury, engineering, compliance, external auditor Board report + BSP submission
Tabletop exercise Semi-annually Scenario walkthrough Executive team, legal, compliance Lessons learned document
Failover drill Quarterly Anchor failover/failback Engineering, anchor ops Technical runbook update
Emergency Protocol drill Annually Full TEP simulation Treasury, CTO, CFO, Compliance, anchor Drill report with remediation items

5.3 Stress Test Results Classification

Result Criteria Response
Pass All recovery targets met within specified timeframes Documented, reported
Conditional Pass Recovery targets met with minor deviations (<10% time overrun) Remediation plan for deviations, tracked to closure
Fail Recovery targets not met, material gaps identified Mandatory remediation plan within 10 business days, re-test within 30 days

5.4 Stress Test Execution Requirements

Each stress test must include:

  1. Pre-test baseline: Document current system state, NAV ratio, buffer levels, anchor distribution.
  2. Test scenario injection: Simulate the trigger conditions in a controlled environment (staging replica of production).
  3. Monitoring: Observe system behavior, alert triggers, automated responses, manual intervention points.
  4. Measurement: Record time-to-detection, time-to-response, time-to-recovery for each metric.
  5. Post-test analysis: Compare actual results against expected response and recovery targets.
  6. Documentation: Full test report with findings, deviations, recommendations.
  7. Remediation tracking: Any gaps logged as Jira tickets with assigned owners and deadlines.

6. Liquidity Buffer Management

6.1 Buffer Calculation

Base buffer = 15% of rolling 30-day average daily disbursement volume.

Buffer = 0.15 × (SUM(daily_disbursements[last_30_days]) / 30)

Buffer composition:

  • Held as cash in the reserve trust accounts across anchors (proportional to anchor distribution).
  • Not invested in any instrument with maturity or market risk.
  • Visible as a separate line item in daily NAV reconciliation.

Buffer adequacy check:

  • Performed daily as part of NAV reconciliation.
  • If buffer < required level, alert generated and restoration plan triggered.
  • Buffer calculation reviewed monthly by Treasury Committee.

6.2 Buffer Adjustment Triggers

Trigger Adjustment Approval Effective Timeline
Fraud rate >0.1% of volume +5% buffer Compliance Officer + CTO Within 24 hours
Anchor delay incidents (2+ in 30 days) +5% buffer Treasury Manager Within 24 hours
Seasonal surge (planting/harvest) +10% temporary Program Administrator Pre-season, time-bound
Multi-anchor setup (3+ anchors) -3% buffer (diversification benefit) Treasury Manager + CTO Within 5 business days
Stress test fail +10% buffer mandatory CTO + CFO Within 24 hours
NAV variance >0.01% (any occurrence) +5% buffer Treasury Manager + CTO Within 24 hours
BSP directive As specified Compliance Officer As directed
Anchor credit rating downgrade +5% buffer Treasury Manager Within 48 hours

Buffer adjustment rules:

  • Multiple triggers are cumulative (e.g., fraud spike + stress test fail = +15%).
  • Buffer cannot fall below 10% under any circumstances (absolute floor).
  • Temporary adjustments (seasonal) automatically revert after specified period.
  • All buffer changes logged with trigger, approval, and effective date.

6.3 Buffer Monitoring & Reporting

  • Real-time buffer dashboard visible to treasury team (Anchor SLA Monitoring Dashboard).
  • Daily buffer status included in NAV reconciliation report.
  • Buffer breach alert (below required level): immediate notification to Treasury Manager and CTO via PagerDuty.
  • Buffer restoration plan required within 4 hours of breach detection.
  • Weekly buffer trend analysis included in Treasury Committee weekly report.
  • Monthly buffer adequacy assessment included in internal attestation memo.

6.4 Anchor Funding Request Procedure

When additional liquidity is required to restore buffer levels:

  1. Funding calculation: Treasury calculates required amount per anchor (proportional to target distribution).
  2. Funding request: Formal request sent to each anchor with amount and deadline (T+1 or T+0 for emergencies).
  3. Anchor confirmation: Anchor confirms ability to fund (within 2 hours for emergencies, 24 hours for routine).
  4. Fund receipt: Anchor transfers funds to trust account; system confirms receipt via bank API.
  5. Buffer recalculation: System recalculates buffer; confirms target achieved.
  6. Confirmation: Treasury Manager confirms restoration; notification to Treasury Committee.
  7. Documentation: Funding event logged with amounts, timestamps, and anchor responses.

7. Monthly Attestation Process

7.1 Internal Attestation (Monthly)

Conducted by: Anchor Treasury Team + Platform Treasury Timeline: Within 5 business days of month-end

Steps:

  1. Extract month-end bank balance (certified by anchor via signed API response or bank statement).
  2. Extract month-end on-chain supply (from Horizon snapshot at 23:59:59 PHT on last day of month).
  3. Extract month-end Obligation Ledger state (all obligation statuses as of 23:59:59 PHT).
  4. Perform three-way reconciliation (bank float ↔ on-chain supply ↔ Obligation Ledger).
  5. Document any variances and resolutions from the month.
  6. Generate Merkle proof export of Obligation Ledger snapshot for audit verification.
  7. Prepare internal attestation memo with:
    • NAV ratio summary (daily values for the month).
    • Variance log and resolution status.
    • Investigation case summary (opened, closed, outstanding).
    • Circuit breaker events (if any).
    • Buffer level status.
    • Anchor distribution and concentration metrics.
    • Stress test results (if any conducted during the month).
  8. Treasury Manager sign-off.

Attestation memo distribution:

  • Treasury Manager (sign-off).
  • CTO (review).
  • Compliance Officer (regulatory compliance check).
  • External auditor (pre-review, if engaged).
  • Board of Directors (summary, if material findings).

7.2 External Attestation (Quarterly)

Conducted by: BSP-accredited independent audit firm Timeline: Within 15 business days of quarter-end

Steps:

  1. Auditor receives access to:
    • Bank statements (certified by anchor).
    • On-chain data (Horizon snapshots, transaction logs).
    • Obligation Ledger (full export with Merkle proofs).
    • Internal attestation memos (3 months).
    • Investigation case files.
    • Circuit breaker event logs.
    • Stress test reports.
    • Treasury Committee meeting minutes.
  2. Auditor performs independent verification of 1:1 backing:
    • Direct confirmation with anchor bank (bank confirmation letter).
    • Independent on-chain supply verification (separate Horizon instance).
    • Independent Obligation Ledger reconciliation.
  3. Auditor reviews reconciliation procedures and variance handling:
    • Sample of daily reconciliation reports.
    • Sample of investigation cases (open and closed).
    • Maker-checker compliance testing.
    • System access controls review.
  4. Auditor samples Obligation Ledger entries and verifies Merkle proofs:
    • Minimum sample: 30 entries (statistically significant).
    • Include entries from each status type (PENDING, SETTLED_ONCHAIN, CONFIRMED_FIAT, CLOSED, emergency).
    • Verify each sample entry's Merkle proof against on-chain Merkle root.
  5. Auditor issues attestation opinion:
    • Unqualified: Reserves fully backed, controls effective.
    • Qualified: Minor exceptions noted.
    • Adverse: Material misstatement or non-compliance.
    • Disclaimer: Unable to form opinion.
  6. Report shared with platform, anchor, and BSP (if required).

7.3 Annual Comprehensive Audit

Conducted by: BSP-accredited audit firm Timeline: Within 60 days of fiscal year-end

Scope:

Audit Area Activities
Full reserve verification 1:1 backing confirmed for every day of the year
Internal controls assessment Access controls, segregation of duties, change management, incident management
BSP/AMLC/DPA compliance assessment Regulatory filing review, transaction monitoring review, data protection audit
Stress test validation Annual full suite results reviewed and validated
Operational risk assessment Key risk indicators, loss events, near-miss analysis
IT general controls review Application controls, infrastructure security, backup and disaster recovery
Emergency Settlement Protocol readiness Drill results, TEP activation history, post-emergency reviews
Treasury governance Treasury Committee effectiveness, policy compliance, Board oversight
Anchor relationship management SLA compliance, performance review, risk assessment
Business continuity planning BCP/DRP adequacy, testing results, update currency

Output:

Annual audit report submitted to Board of Directors and BSP (if required).

Report sections:

  1. Executive Summary.
  2. Audit Opinion.
  3. Reserve Verification (daily NAV analysis for the year).
  4. Internal Controls Assessment.
  5. Regulatory Compliance Assessment.
  6. Stress Test Validation.
  7. Emergency Preparedness Assessment.
  8. Findings and Recommendations.
  9. Management Response and Action Plan.
  10. Appendices (detailed test results, sample selections, data sources).

8. Third-Party Auditor Reporting Template

8.1 Attestation Report Structure

RESERVE ATTESTATION REPORT
────────────────────────────────────────────────────
Report Period:    [Month / Quarter / Year]
Prepared by:      [Auditor Name, Firm, BSP Accreditation Number]
Date:             [Report Date]
Reference No.:    [AUDIT-YYYY-NNN]
────────────────────────────────────────────────────

1. EXECUTIVE SUMMARY
   ─────────────────
   1.1 Scope of Engagement
       - Describe the scope: reserve verification, reconciliation review,
         internal controls assessment, compliance review.
       - Period covered.
       - Standards applied (BSP guidelines, ISA, etc.).

   1.2 Overall Opinion
       - [Unqualified / Qualified / Adverse / Disclaimer of Opinion]

   1.3 Key Findings
       - Summary of material findings (if any).
       - Summary of recommendations.

2. RESERVE VERIFICATION
   ─────────────────────
   2.1 Bank Balance as of [date]
       - Anchor A: PHP [amount] (confirmed via bank letter dated [date])
       - Anchor B: PHP [amount] (confirmed via bank letter dated [date])
       - Total Reserve: PHP [amount]

   2.2 On-Chain Supply as of [date]
       - Total PHP-pegged tokens: PHP [amount]
       - Verified via Horizon API at [URL], block [number]

   2.3 Obligation Ledger Total as of [date]
       - Total non-CLOSED obligations: PHP [amount]
       - Total CLOSED obligations (historical): PHP [amount]
       - Merkle root: [hash]
       - Merkle proof verification: [verified / N exceptions noted]

   2.4 NAV Ratio
       - NAV = Total Reserve / On-Chain Supply = [value]
       - Three-way reconciliation result: [matched / variance X%]
       - Variance classification: [Normal / Watch / Alert / Critical]

   2.5 Merkle Proof Verification
       - Sample size: [N entries]
       - Entries verified: [N]
       - Exceptions: [N]
       - Exception details: [list if any]

3. RECONCILIATION PROCEDURES REVIEW
   ────────────────────────────────
   3.1 Daily Reconciliation Process Assessment
       - Procedure design adequacy: [Adequate / Needs Improvement]
       - Operating effectiveness: [Effective / Exceptions noted]

   3.2 Variance Handling Assessment
       - Variance classification accuracy: [Accurate / Exceptions]
       - Response timeliness: [Within SLA / Exceptions]
       - Investigation quality: [Satisfactory / Needs Improvement]

   3.3 Maker-Checker Compliance
       - Sample tested: [N transactions]
       - Compliance rate: [X%]
       - Exceptions: [describe]

   3.4 Investigation Queue Review
       - Open cases: [N]
       - Closed cases (period): [N]
       - Average resolution time: [X hours/days]
       - SLA compliance: [X%]

4. INTERNAL CONTROLS ASSESSMENT
   ─────────────────────────────
   4.1 Access Controls
       - RBAC configuration: [Adequate / Gaps]
       - Key management: [Secure / Gaps]
       - Privileged access monitoring: [Effective / Gaps]

   4.2 Segregation of Duties
       - Maker-Checker enforcement: [Enforced / Exceptions]
       - Role separation: [Adequate / Gaps]

   4.3 Change Management
       - Deployment process: [Controlled / Gaps]
       - Version control: [Adequate / Gaps]
       - Rollback capability: [Tested / Not tested]

   4.4 Incident Management
       - Incident logging: [Complete / Gaps]
       - Response timeliness: [Within SLA / Exceptions]
       - Post-incident review: [Conducted / Not conducted]

   4.5 Emergency Settlement Protocol Readiness
       - TEP documentation: [Current / Outdated]
       - Drill results: [Satisfactory / Gaps]
       - Signatory readiness: [Confirmed / Gaps]

5. COMPLIANCE ASSESSMENT
   ──────────────────────
   5.1 BSP Circular Compliance
       - Applicable circulars reviewed: [list]
       - Compliance status: [Compliant / Non-compliant items]

   5.2 AMLC Obligation Compliance
       - Transaction monitoring: [Effective / Gaps]
       - STR/CTR filing: [Timely / Delays noted]
       - KYC procedures: [Adequate / Gaps]

   5.3 DPA Compliance
       - Data protection controls: [Adequate / Gaps]
       - Breach notification capability: [Tested / Not tested]
       - Data retention: [Compliant / Gaps]

6. FINDINGS AND RECOMMENDATIONS
   ─────────────────────────────
   Finding 1: [Description]
     - Severity: [High / Medium / Low]
     - Root cause: [Description]
     - Recommendation: [Description]
     - Management response: [Description]
     - Target date: [Date]

   Finding 2: [...]

7. OPINION
   ───────
   [Full text of the auditor's opinion, including basis for opinion,
    any qualifications, and emphasis of matter paragraphs.]

8. SIGNATURES
   ───────────
   Auditor Name:    [Name]
   Title:           [Title]
   Firm:            [Firm Name]
   BSP Accred. No.: [Number]
   Signature:       _________________________
   Date:            [Date]
   Firm Seal:       [Affixed]

────────────────────────────────────────────────────
End of Report

8.2 Opinion Definitions

Opinion Type Meaning Implication Required Action
Unqualified Reserves fully backed, controls effective, three-way match confirmed Clean bill of health None; maintain current procedures
Qualified Minor exceptions noted, substantially compliant Remediation within 30 days required Remediation plan submitted to BSP within 10 business days
Adverse Material misstatement or non-compliance Immediate regulatory notification, program review TEP activation considered; Board emergency session
Disclaimer Unable to form opinion (access denied, records incomplete) Treated as adverse until resolved Immediate remediation; re-engagement with auditor

8.3 Report Distribution

Recipient Format Timeline Purpose
BSP PDF (signed) Within 5 business days of issuance Regulatory compliance
AMLC PDF (signed) If requested Regulatory compliance
Board of Directors PDF + presentation Within 10 business days Governance oversight
Treasury Committee PDF Within 5 business days Operational response
External auditor (next cycle) PDF With report Continuity
Anchor banks Summary letter Within 10 business days Relationship management
Public (annual) Redacted PDF Within 60 days of fiscal year-end Transparency

9. Treasury Governance

9.1 Treasury Committee

Attribute Detail
Chair CFO
Members CTO, Treasury Manager, Compliance Officer, independent director (non-executive)
Quorum 3 members including CFO or CTO
Meeting Frequency Monthly (routine), ad-hoc (emergency)
Decision Rule Majority vote; unanimous required for material policy changes
Secretary Compliance Officer (records minutes, tracks action items)
Invitees External auditor (quarterly), anchor representatives (as needed), Board observer (non-voting)

Treasury Committee responsibilities:

  • Approve treasury policies and procedures.
  • Review monthly NAV reconciliation reports.
  • Review investigation case status and resolution adequacy.
  • Approve buffer adjustments beyond automated thresholds.
  • Review stress test results and mandate remediation.
  • Approve anchor onboarding/offboarding.
  • Review external attestation reports.
  • Oversee Emergency Settlement Protocol readiness.
  • Escalate material issues to Board of Directors.

9.2 Treasury Policy Changes

All changes to treasury policy require:

  1. Written proposal with impact analysis (financial, operational, regulatory, technical).
  2. Treasury Committee review and approval (majority vote).
  3. Board notification for material changes (defined as: changes to reserve model, NAV thresholds, circuit breaker levels, buffer percentages).
  4. Documentation in policy registry with version history (who, what, when, why).
  5. Testing in sandbox before production deployment (simulated transactions, reconciliation validation).
  6. Maker-checker deployment approval (Treasury Manager proposes, CTO approves).
  7. 90-day rollback capability (previous version preserved and deployable within 4 hours).
  8. Regulatory notification if change affects BSP/AMLC reporting obligations.

Policy registry structure:

Field Description
Policy ID Unique identifier (POL-YYYY-NNN)
Version Semantic version (major.minor.patch)
Effective date When the policy takes effect
Expiry date If time-bound
Superseded by Reference to replacement policy
Author Who drafted the policy
Approved by Treasury Committee vote record
Change log Summary of changes from previous version
Test results Sandbox test report reference

9.3 Key Treasury Metrics Dashboard

Metric Current Value Target Alert Threshold Monitoring Frequency
NAV ratio [value] 1.0000 <0.9999 or >1.0001 Daily
Liquidity buffer [value] >=15% <15% Real-time
Anchor concentration (max) [value] <=40% >40% Daily
Daily reconciliation status [complete/pending/exception] Complete Exception Daily
Outstanding investigation cases [count] 0 >0 for >24 hours Hourly
Stress test status [pass/conditional/fail] Pass Any fail Quarterly
Last attestation date [date] Within 30 days >30 days overdue Monthly
Circuit breaker level [Green/Yellow/Orange/Red] Green Orange or Red Real-time
Emergency Protocol status [standby/active/post-emergency] Standby Active Real-time
Merkle proof export status [current/overdue] Current (daily) >24 hours overdue Daily
Buffer utilization [value] >=100% of required <100% Real-time
Anchor SLA compliance [value] >=99.9% <99.5% Daily
Maker-checker compliance rate [value] 100% <100% Daily
Open investigation cases >48h [count] 0 >0 Hourly
Regulatory filing status [on-time/pending/overdue] On-time Any overdue Per filing deadline

9.4 Treasury Reporting Calendar

| Report | Frequency | Recipients | Deadline | |---|---|---|---|---| | Daily NAV reconciliation report | Daily | Treasury team, CTO | 00:30 PHT | | Weekly treasury summary | Weekly | Treasury Committee | Monday 10:00 | | Monthly internal attestation | Monthly | Treasury Committee, Board summary | 5th business day | | Quarterly external attestation | Quarterly | BSP, Board, Treasury Committee | 15th business day | | Annual comprehensive audit | Annually | Board, BSP | 60 days post fiscal year-end | | Stress test report | Quarterly | Treasury Committee, Board | 10 business days post-test | | Buffer status report | Daily | Treasury team | 00:30 PHT | | Anchor performance scorecard | Quarterly | Treasury Committee, Anchor | 10 business days post-quarter | | Regulatory filing (BSP) | As required | BSP | Per BSP deadline | | Regulatory filing (AMLC) | As required | AMLC | Per AMLC deadline |

9.5 Treasury Key Performance Indicators (KPIs)

KPI Target Measurement Consequence of Miss
NAV accuracy 1.0000 +/- 0.005% Daily reconciliation Investigation, potential TEP
Reconciliation timeliness 100% completed by 00:15 PHT System log Process review
Investigation resolution SLA 100% within SLA Case management system Escalation, remediation
Maker-checker compliance 100% Audit log review Policy violation, retraining
Buffer adequacy >=100% of required Real-time calculation Funding request, potential circuit breaker
Anchor SLA compliance >=99.9% SLA monitoring dashboard Anchor review, potential offboarding
Stress test pass rate 100% pass or conditional pass Stress test reports Remediation, re-test
Attestation timeliness 100% on schedule Report log Regulatory notification
Policy compliance 100% Internal audit Corrective action plan
Incident response time Within defined SLA per severity Incident management system Post-incident review

10. Operational Procedures

10.1 Daily Operations Checklist

Treasury Analyst (daily, 08:00–09:00 PHT):

  • Review overnight NAV reconciliation report.
  • Verify all three data sources received (bank, Horizon, Obligation Ledger).
  • Check for any variance alerts or watch-level classifications.
  • Review outstanding investigation cases.
  • Confirm buffer level above required threshold.
  • Check anchor SLA dashboard for any performance degradation.
  • Verify circuit breaker status (should be Green).
  • Review daily Merkle proof export status.
  • Log any anomalies in treasury operations journal.

Treasury Manager (daily, 09:00–10:00 PHT):

  • Review Treasury Analyst report.
  • Approve/reject any pending maker-checker items.
  • Review investigation cases requiring escalation.
  • Check anchor concentration metrics (rebalance if approaching 40%).
  • Review any regulatory correspondence.
  • Sign off on daily treasury status.

Compliance Officer (daily, 10:00–11:00 PHT):

  • Review NAV reconciliation for regulatory reporting triggers.
  • Monitor AMLC transaction alerts.
  • Review investigation cases with compliance implications.
  • Check regulatory filing deadlines.
  • Update compliance risk register.

10.2 Weekly Treasury Operations

Treasury Committee Weekly Call (Monday, 14:00 PHT):

  1. Review weekly NAV trend (7-day rolling average).
  2. Review investigation case status (opened, closed, outstanding).
  3. Review buffer trend and adequacy forecast (next 30 days).
  4. Review anchor performance metrics.
  5. Review circuit breaker proximity to thresholds.
  6. Review regulatory developments.
  7. Review upcoming attestations or audits.
  8. Action item review and assignment.

10.3 Monthly Treasury Operations

Month-End Close (Last business day of month):

  1. Final daily reconciliation for the month.
  2. Obligation Ledger month-end snapshot.
  3. Merkle root computation and on-chain anchoring.
  4. Bank balance confirmation request to all anchors.
  5. Treasury operations journal compiled.

Internal Attestation (Within 5 business days of month-end):

  1. Three-way reconciliation with certified data.
  2. Attestation memo preparation.
  3. Treasury Manager sign-off.
  4. Distribution to stakeholders.

Treasury Committee Monthly Meeting (Within 10 business days of month-end):

  1. Monthly NAV summary and trend analysis.
  2. Variance analysis (all instances above 0.005%).
  3. Investigation case summary.
  4. Buffer adequacy assessment.
  5. Anchor distribution review.
  6. Stress test calendar review.
  7. External attestation preparation (if quarter-end).
  8. Policy change proposals (if any).

10.4 Quarterly Treasury Operations

External Attestation Engagement:

  1. Engage external auditor (standing engagement or per-quarter).
  2. Provide data access and documentation.
  3. Coordinate anchor bank confirmations.
  4. Review draft report.
  5. Address auditor queries.
  6. Receive final report.
  7. Distribute to stakeholders.
  8. File with BSP (if required).

Stress Test Execution:

  1. Select scenario for the quarter (rotation through all 8 scenarios).
  2. Prepare test environment and baseline.
  3. Execute test.
  4. Document results.
  5. Classify result (Pass/Conditional/Fail).
  6. Report to Treasury Committee.
  7. Remediate any gaps.

Anchor Performance Review:

  1. Compile quarterly scorecard for each anchor.
  2. Review SLA compliance history.
  3. Assess risk profile changes.
  4. Determine if rebalancing needed.
  5. Document findings and recommendations.

10.5 Annual Treasury Operations

Annual Comprehensive Audit:

  1. Engage external auditor.
  2. Coordinate full-scope audit (all sections per Section 7.3).
  3. Support auditor fieldwork.
  4. Review draft audit report.
  5. Prepare management response.
  6. Receive final report.
  7. Present to Board of Directors.
  8. File with BSP (if required).
  9. Implement remediation plan.

Full Stress Test Suite:

  1. Execute all 8 stress test scenarios.
  2. Include anchor participation.
  3. Include external auditor observation.
  4. Compile comprehensive report.
  5. Submit to Board and BSP.

Annual Treasury Policy Review:

  1. Review all treasury policies for currency and adequacy.
  2. Propose updates based on lessons learned.
  3. Treasury Committee approval.
  4. Board notification of material changes.
  5. Update policy registry.

Anchor Contract Renewal:

  1. Review SLA terms.
  2. Negotiate improvements based on performance history.
  3. Execute renewal or initiate offboarding.
  4. BSP notification of changes.

11. Regulatory Compliance

11.1 BSP Reporting Obligations

Report Frequency Deadline Recipient Format
Reserve position report Monthly 10th business day BSP BSP-prescribed format
NAV reconciliation summary Monthly 10th business day BSP PDF + data file
External attestation report Quarterly 15 business days post-quarter BSP Auditor-signed PDF
Annual audit report Annually 60 days post fiscal year-end BSP Full audit report
Material event notification As occurred Within 24 hours BSP Written notification
Emergency Protocol activation As occurred Within 2 hours BSP Written notification
Circuit breaker Orange/Red activation As occurred Within 4 hours BSP Written notification
Stress test results Annually With annual audit BSP Summary report

11.2 AMLC Obligations

Obligation Requirement Timeline
Covered Transaction Report (CTR) Cash transactions >= PHP 500,000 Within 5 business days
Suspicious Transaction Report (STR) Any suspicious transaction regardless of amount Within 5 business days
Covered Person registration Registration with AMLC as Virtual Asset Service Provider Before commencing operations
KYC/AML program Documented AML/CFT program, risk assessment, policies Before commencing operations, updated annually
Record keeping All transaction records, KYC documents 5 years minimum
Training AML/CFT training for relevant staff Annually
Independent audit AML/CFT program effectiveness audit Annually

11.3 DPA (Data Privacy Act) Obligations

Obligation Requirement Timeline
DPO registration Register Data Protection Officer with NPC Before processing
Privacy Impact Assessment For systems processing personal data Before system launch, updated annually
Breach notification Notify NPC of personal data breach Within 72 hours of knowledge
Data subject rights Respond to data subject access requests Within 30 days
Privacy notice Publish privacy notice to beneficiaries Before collecting data
Record of processing activities Maintain processing inventory Ongoing
Annual review Privacy program effectiveness review Annually

12. Document Control

Attribute Value
Document ID TREAS-PB-001
Version 1.0
Effective Date Upon Board approval
Review Cycle Annually
Owner Treasury Manager
Approver CFO + Board of Directors
Classification Confidential
Retention 10 years

Revision History

Version Date Author Changes Approved By
1.0 [Date] [Author] Initial release [CFO Name]

📝 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.