# Security Attack Surface — Every Vulnerability In M-Pass Postpaid

**Role:** Security Auditor / Technology Skeptic — Ministry of Transport  
**System:** M-Pass Postpaid Account-Based Tolling (POC proposal)  
**Date:** June 17, 2026  
**Opponent:** Ginnie (System Architect)

---

## (a) Executive Statement — Overall Security Posture Score

**Score: 4.5 / 10**

The M-Pass Postpaid architecture has some genuinely good decisions — payment off the lane critical path, no raw PAN at DOH, and a 6-failure-mode testing plan — but these are **design intentions, not implemented controls**. The architecture documentation is notably **vague on every specific security implementation detail**: no mention of authentication protocols (mTLS? OAuth2? API keys?), no encryption key management plan, no network segmentation described, no SIEM/logging architecture, no penetration testing timeline, and — most critically — **no security architecture diagram at all**. The entire security posture rests on a PSP's tokenization service whose controls are neither specified nor auditable by DOH pre-POC.

For a system that will handle citizen payment credentials, trip pattern data, and fleet billing for the Ministry of Transport, landing at a POC with no security architecture is **a material risk that could stall or kill the project at any gate**.

**Rating breakdown:**
| Dimension | Score | Rationale |
|---|---|---|
| Threat modeling | 3/10 | No threat model exists in the proposal. Attack surfaces are unaddressed. |
| PCI DSS readiness | 5/10 | Tokenization is good, but trip + tag data has its own compliance obligations. |
| Authentication | 2/10 | **Nothing is specified.** No protocol, no architecture, no key management. |
| Resilience | 6/10 | Off-critical-path payment is good. Failure test plan is well-structured. |
| Fraud detection | 4/10 | One fraud test exists; no real-time fraud model is described. |
| Insider threat | 2/10 | Call center agent access, DOH billing admin access — no controls described. |
| Third-party risk | 3/10 | PSP dependency acknowledged; no contractual controls or exit plan specified. |
| Data leakage prevention | 3/10 | Data minimization acknowledged; no enforcement mechanism described. |

---

## (b) Attack Surface Map

### Attack Vector #1 — Toll Lane Spoofing (Trip Event Injection)

**Severity:** 🔴 CRITICAL  
**Vector:** An attacker with network access to the toll lane infrastructure sends forged trip events to the toll event API. Fake trips = fake charges. If the system charges by trip, a forged event directly costs the citizen money. If the system bills via daily threshold, forged events can trigger thresholds early, causing premature billing or account suspension.

**Exploit Scenario:**
1. Attacker compromises a roadside ethernet switch or wireless bridge connecting a toll lane to the DOH network
2. Attacker replays or crafts toll event messages (tag ID, plaza, lane, timestamp, vehicle class)
3. 10,000 fake trips injected over 24 hours
4. Postpaid accounts of targeted vehicles trigger mass billing, disputes, or suspension
5. At scale, this is a **denial-of-service against the billing pipeline** OR a **fraud vector** if the attacker controls the target account

**Current Protection (from proposal):** "Duplicate detection" based on tag/plate/event time/plaza/lane/vehicle class. This detects exact duplicates but **cannot detect novel forged trips** from a different lane at a different time with the same tag.

**Recommended Fix:**
- mTLS between toll lane controllers and the toll event ingestion API. Every lane device must present a hardware-bound client certificate.
- Sequence-numbered, HMAC-signed trip events per lane device. DOH core rejects events without valid HMAC.
- Anomaly detection on lane event volume — if Lane 7 at Plaza 3 suddenly emits 5,000 events/hour instead of its normal 200, alert instantly.
- **Do not rely on application-layer deduplication alone.** Prove that a compromised lane cannot inject valid-looking events.

---

### Attack Vector #2 — Token Reference MITM Between DOH and PSP

**Severity:** 🟡 HIGH  
**Vector:** The token reference flows from DOH to PSP for authorization and capture. If the path between DOH's payment orchestrator and the PSP gateway is compromised, an attacker can intercept token references and attempt to replay or misuse them.

**Exploit Scenario:**
1. Attacker gains position on the DOH-PSP network segment (compromised VPN, rogue switch, DNS hijack)
2. Token reference for User A's card intercepted during a capture call
3. Attacker replays the token reference against a different DOH-controlled endpoint
4. If the PSP lacks replay detection on token usage, this creates unauthorized charges

**Current Protection:** "Token reference only, no raw PAN." This is correct but insufficient — tokens themselves are bearer instruments in most PSP implementations.

**Recommended Fix:**
- mTLS between DOH payment orchestrator and PSP (not just TLS — **mutual** TLS, so the PSP authenticates DOH's certificate too)
- Token binding: the PSP should bind each token to the DOH merchant ID so the token is worthless if replayed against a different merchant
- Request-level HMAC signatures on all payment API calls, not just token-based auth
- Rate limiting on token usage — one token should not generate 50 capture attempts in 60 seconds

---

### Attack Vector #3 — Consent Database as Single Point of Failure

**Severity:** 🟡 HIGH  
**Vector:** The consent database is the **authoritative source for whether a card is authorized for postpaid billing**. If this database is corrupted, deleted, or compromised, the entire billing system becomes inoperable or fraudulent.

**Exploit Scenario (Corruption):**
1. Ransomware or DB corruption hits the consent database
2. DOH cannot determine which cards are authorized for billing
3. All postpaid billing stops — or worse, billing continues against unverified tokens
4. Recovery requires reconciliation against PSP records (assuming PSP stores who consented, which they typically don't)

**Exploit Scenario (Insider Modification):**
1. A DOH database admin with `UPDATE` access modifies the consent flag for a vehicle
2. An unauthorized card is linked to a vehicle
3. Toll charges flow to the wrong cardholder
4. Detection requires cross-referencing consent timestamps, IP addresses, and audit logs

**Current Protection:** Not described. No replication strategy, no backup SLA, no immutable audit log on consent changes.

**Recommended Fix:**
- Consent database must be **append-only with versioned records**. Consent records are never updated in place — a new row is written with a timestamp, and the "current consent" is the latest row per vehicle.
- Every consent change must be logged with: who (API key / user ID), what (consent granted / revoked / modified), when (server timestamp), source IP, and user-agent.
- **Geo-redundant replication** with RPO < 1 minute. Consent is the crown jewel — losing it means losing the ability to bill.
- **Offline backup**: daily encrypted backup to a separate environment, tested quarterly for restore.

---

### Attack Vector #4 — Call Center Agent Insider Threat (Data Leakage & Fraud)

**Severity:** 🔴 CRITICAL  
**Vector:** A call center agent has access to citizen account data: trip history, vehicle registration, tag ID, billing status, and — even though DOH doesn't store raw PAN — the agent can see **trip patterns, vehicle information, and personally identifiable information**. Two distinct threats exist: (1) data sale / stalking via trip patterns, (2) billing manipulation.

**Exploit Scenario (Data Sale):**
1. Call center agent copies trip history for a fleet of logistics vehicles belonging to Company X
2. Agent sells trip pattern data — routes, frequency, timing — to a competitor (Company Y)
3. Company Y now knows Company X's delivery routes and schedules
4. Detection is nearly impossible without data exfiltration monitoring on agent workstations

**Exploit Scenario (Billing Fraud):**
1. Agent has ability to mark a billing dispute as "resolved" or adjust charges
2. Agent processes fraudulent disputes for vehicles linked to a personal account managed by an accomplice
3. Multiple small adjustments (฿50–฿200 each) that escape automated fraud detection
4. Over months, this produces significant unauthorized write-offs

**Current Protection:** Not described. No mention of role-based access control, no audit of agent screen views, no "view-only vs. modify" distinction, no data masking.

**Recommended Fix:**
- **Trip data masking by default.** Agent should see only what's necessary to resolve the inquiry: "last 5 trips, dates only, no pattern analysis." Full trip history requires supervisor approval with logged reason.
- **No modify-first workflows.** All billing adjustments should be "request change" → "supervisor approves" → "system executes." Agents never directly modify billing records.
- **Screen recording** on all agent workstations with anomaly detection on data access patterns.
- **Read-only dashboard** for call center. Separated from billing modification console, which requires two-factor authentication and supervisor co-sign.

---

### Attack Vector #5 — Reconciliation Pipeline Data Integrity (Layer 1–8)

**Severity:** 🟡 HIGH  
**Vector:** The 8-layer reconciliation model processes toll event data through (at least): lane log → toll event feed → billing ledger → payment orchestration → PSP → acquirer → statement → dispute. Every handoff between layers is a potential point for data corruption, omission, or injection.

**Exploit Scenario:**
1. An attacker or bug in the reconciliation pipeline drops 0.5% of toll events at Layer 3 (toll event feed → billing ledger)
2. 0.5% is below the "detectable threshold" (𑁋 one test scenario checks for 5 missing out of 200 = 2.5% detection floor)
3. Over a month, thousands of trips go unbilled
4. Revenue leakage: the system hemorrhages money silently
5. Citizens do not report because they see fewer charges — this is a **negative fraud** that incentives silence

**Current Protection:** One test scenario (Test 6) injects a 2.5% mismatch. No test for sub-1% silent drops. No reconciliation of lane event counts as a primary metric (every lane should report "I processed N trips today" as a separate data stream).

**Recommended Fix:**
- **Independent lane event count stream.** Every toll lane reports a daily signed counter: "Lane X Plaza Y — 1,247 trips today." The billing pipeline independently counts events. If counters diverge by more than 0.1%, investigate.
- **Layer 0: physical cross-check.** Toll plaza gate barrier opens = one trip. This should correlate with lane event within a known tolerance. If 1,000 barriers opened but only 995 events recorded, that's an anomaly even if no individual event was dropped.
- **All 8 layers must have hash-chain integrity.** Each layer's output is cryptographically hashed and the hash submitted to the next layer. A mismatch at any layer is detectable without comparing every row.

---

### Attack Vector #6 — DDoS Against Payment Orchestration Layer

**Severity:** 🟡 HIGH  
**Vector:** The proposal states payment is "not in lane critical path," which is correct for immediate lane operation. However, when PSP is down or the payment orchestration layer is DDoS'd, **billing accumulates as unbilled trips**. At POC scale (5,000–10,000 consumers), this is manageable. At national scale (500,000+ postpaid users), a 4-hour outage produces hundreds of thousands of queued payment attempts — and when the PSP recovers, the **thundering herd** of retries can overwhelm it again.

**Exploit Scenario:**
1. Payment orchestration API is targeted by a DDoS attack (L7 HTTP flood)
2. API gateway collapses; health checks start failing
3. Toll events continue arriving in the ledger (ledger is separate, survives)
4. After 4 hours, ฿2M+ worth of unpaid tolls are queued
5. Payment gateway recovers but 50,000+ queued capture attempts arrive simultaneously
6. Gateway collapses again — cascading failure
7. Exposure grows exponentially

**Current Protection:** "Trip events stored in ledger, payment attempts queue and process once PSP recovers." No rate limiting on replay. No circuit breaker described. No partial-drain mechanism.

**Recommended Fix:**
- **Circuit breaker pattern** at payment orchestration layer. If PSP response time > 5 seconds or error rate > 10%, gracefully degrade to "queued" status without hitting the PSP.
- **Sliding-window rate limiter** for payment recovery. Replay queued events at a controlled rate (e.g., 500/minute), not all at once.
- **Separate API gateway** for payment orchestration vs. citizen-facing dashboard. Lane events hit a completely different endpoint and should never be affected by payment-orchestration DDoS.
- Load test the queue drain scenario **before POC go-live**, not after.

---

### Attack Vector #7 — PCI DSS Scope Creep: Toll Event Data as Sensitive Data

**Severity:** 🟡 HIGH  
**Vector:** The proposal claims "no raw PAN, therefore SAQ A." This is correct **for the card data path only**. The toll event data — trip timestamps, tag IDs, vehicle class, plaza location — combined with account identifiers (name, phone, vehicle registration) creates a **personally identifiable trip pattern dataset** that may trigger additional compliance obligations under PDPA and potentially under PCI DSS if the tag ID or account identifier acts as a quasi-PAN for correlation.

**Exploit Scenario:**
1. A citizen's trip data (tag ID 1234 → account "Somsak R." → vehicle "กข 1234 กรุงเทพมหานคร") is stored in the toll ledger in plaintext
2. Database breach exposes 50,000 citizens' trip patterns plus linked account information
3. PDPA violation (massive) — trip patterns can reveal home address, workplace, medical appointments, religious attendance
4. While not PCI DSS cardholder data, the **combination of trip + identity data** is arguably more harmful than a card number (which can be replaced; trip history cannot)
5. If the payment orchestrator logs the token reference alongside trip data, the token reference **becomes cardholder data** in the DOH environment and SAQ A is invalidated

**Current Protection:** No encryption at rest mentioned for toll ledger. No separation between toll event data and payment token data in the same database. No data classification policy described.

**Recommended Fix:**
- **Encrypt trip data at rest.** Full database-level TDE at minimum; column-level encryption for trip patterns with access via application-layer permission.
- **Strict separation** between toll event pipeline and payment pipeline databases. Cross-querying requires justification and audit.
- **Data classification framework** before Day 1 of POC. Every field tagged: Public, Internal, Sensitive, Restricted. Trip patterns tagged as Sensitive minimum.
- **Token reference in DOH logs is cardholder data.** Strip token references from application logs. If logging for debugging, mask to last 4 characters.

---

### Attack Vector #8 — The "No Raw PAN" Illusion (Network Token Flow)

**Severity:** 🔴 CRITICAL  
**Vector:** The proposal states "DOH stores token only." The question is: *which token?* If it's a PSP-issued payment token (a surrogate for the PAN that only the PSP can reverse), this is SAQ-A compliant. If it's a **network token** (from Visa/Mastercard token vault) that flows through DOH's servers during provisioning, the token **passes through DOH infrastructure** and creates a PCI DSS audit trail problem.

**Exploit Scenario:**
1. PSP's card-on-file provisioning flow requires the citizen to enter card details on a form
2. If the form is **hosted by DOH** (even behind PSP API calls), DOH handles card data in-transit → SAQ A invalidated
3. If provisioning uses a **PSP-hosted iframe or redirect** (correct approach), DOH never touches PAN — SAQ A stands
4. But: if the network token is provisioned via the PSP and stored at DOH, and the PSP is compromised, the attacker can **de-tokenize all DOH's stored tokens** at the network level
5. This is not theoretical — Visa's network tokenization has a de-tokenization API that the merchant (DOH!) can call with the right credentials

**Current Protection:** "Card-on-file via PSP; DOH sees token only." The proposal does not specify whether the token is PSP-issued (safe) or a network token (more useful for recurring billing, but creates PAN-like risk at DOH).

**Recommended Fix:**
- **Mandate PSP-hosted card entry.** DOH must never serve the card entry form, even via API proxying. The citizen enters card details on the PSP's hosted page or redirect URL only.
- **If network tokens are used**, they must be treated as cardholder data at DOH and subject to the same PCI DSS controls as raw PAN. Encrypt at rest, restrict access, audit all reads.
- **Demand from the PSP** a written attestation that DOH is fully out of PCI DSS scope. The PSP must provide a SAQ A eligibility letter — not the architect's opinion, but the PSP's compliance team's written position.
- **De-tokenization controls**: if DOH's merchant ID can de-tokenize, that credential must be HSM-protected, not in a config file.

---

### Attack Vector #9 — Fleet Billing as a Fraud Vehicle

**Severity:** 🟡 HIGH  
**Vector:** Fleet billing aggregates trips across multiple vehicles under one corporate account. The account's credit cap and KYB are checked once. After approval, each linked vehicle's tolls flow to the corporate card. The **aggregation is the vulnerability**: one compromised fleet account means thousands of trips billed to the wrong entity.

**Exploit Scenario (Rogue Employee):**
1. Fleet employee with access to the fleet dashboard adds their personal vehicle under the company account
2. Personal tolls now billed to the company
3. In a fleet of 200 vehicles, one rogue vehicle is hard to spot in aggregate billing
4. Monthly company statement shows 1,100 trips instead of 1,000 — an auditor would need to trip-level audit to catch the 100 rogue trips

**Exploit Scenario (Rental Tourist):**
1. Tourist rents a car, registers a temporary postpaid account with a soon-to-be-cancelled card
2. Charges the tourist rate for 7 days, then card is cancelled, account goes delinquent
3. Rental company is left with no recourse — the card was cancelled, the tourist is in a different country
4. This is not fraud per se, but a **structural bad debt vector** that the proposal acknowledges only at aggregate level

**Current Protection:** "KYB, contract, credit cap, deposit" for fleet. Vehicle-tag linkage exists but no cross-vehicle anomaly detection.

**Recommended Fix:**
- **Vehicle-level trip audit** for fleet accounts. The fleet admin sees total and per-vehicle breakdowns. Any vehicle added mid-cycle is flagged for review.
- **Grace period for new fleet vehicles**: a newly added vehicle cannot generate billings for 24 hours (allow time for administrative review).
- **Rental car use case**: require a refundable deposit (e.g., credit hold of ฿2,000) before postpaid billing is activated. The hold acts as a deterrent against card-cancellation fraud.
- **Real-time velocity check**: if a single fleet account adds 20 vehicles in 24 hours, flag for manual review.

---

### Attack Vector #10 — Authentication and Authorization Architecture (Absent)

**Severity:** 🔴 CRITICAL  
**Vector:** The proposal does not specify how any component authenticates to any other. This is the single biggest security gap in the entire architecture. For a system with 4+ integration points (toll lane → core, PSP → orchestrator, call center → dashboard, citizen → account web portal), the absence of an authentication architecture means **every integration is vulnerable by default**.

**Specific unknowns that would each be a finding in a real audit:**

| Integration | Missing | Risk |
|---|---|---|
| Toll lane → event API | Client certificate? API key? Pre-shared secret? | Lane spoofing (AV #1) |
| DOH payment orchestrator → PSP | mTLS? Basic auth? OAuth2 client credentials? | Token replay (AV #2) |
| PSP → DOH (webhook callback) | Signed payload? HMAC? JWT? | Fake PSP callbacks triggering phantom captures |
| Call center agent → dashboard | LDAP/AD integration? MFA? Session timeout? | Insider threat (AV #4) |
| Citizen web portal → backend | OAuth2? Session management? Rate limiting on login? | Account takeover |
| Fleet admin → fleet API | Scoped API keys? IP allowlists? | Fleet fraud (AV #9) |
| Reconciliation pipeline inter-service | Service mesh mTLS? Mutual auth? | Data integrity (AV #5) |

**Current Protection:** None described. Entirely absent from the proposal.

**Recommended Fix:**
- **Publish an authentication architecture diagram** before the POC. Every arrow between components must name the protocol: "mTLS (client cert rotation every 90 days)" or "OAuth2 client credentials (scoped per service)."
- **Minimize shared secrets.** Each lane device gets a unique certificate with a short expiry (renewed via ACME/EST within the DOH network). No shared API keys across 50 lanes.
- **All citizen-facing authentication** must support MFA from Day 1. Postpaid billing is high-value — a compromised account allows an attacker to view trip history and modify payment method.
- **All service-to-service calls** must include a trace ID (for audit trail) and a claims token (identifying the caller's role, not just identity).

---

### Attack Vector #11 — Side-Channel Data Leakage Through Call Center CRM

**Severity:** 🟡 HIGH  
**Vector:** Even if call center agents cannot modify billing records, they can **query trip history** to resolve citizen inquiries. The CRM system records every inquiry with timestamps. An agent with access to trip history for a specific citizen can reconstruct: home address (trips ending near the same location daily after 18:00), workplace (trips starting near the same location before 09:00), medical appointments (regular trips to a hospital), religious attendance (weekly trips to a specific location on a specific day), and social connections (two vehicles visiting the same residence pattern).

**Exploit Scenario:**
1. Call center agent receives call from Citizen A regarding a billing dispute
2. Agent queries Citizen A's trip history (necessary for the dispute — legitimate access)
3. Agent notes that Citizen A visits a specific hospital every Tuesday
4. Agent sells this information to a competitor insurance company or a stalker
5. Citizen A has no way of knowing their trip data was accessed — no notification mechanism for "your data was viewed"

**Current Protection:** "PDPA compliance" is mentioned as a gate. No specific data minimization for call center access is described. No "view of data" auditing.

**Recommended Fix:**
- **Purpose-limited trip history view.** The agent sees only trips relevant to the current billing period under dispute, not full historical data.
- **"View reason" requirement.** Every trip history query requires the agent to select a reason from a dropdown (dispute, billing inquiry, account verification) with free-text for exceptions. Dropdown selections are audited.
- **Anomaly detection on agent views.** If Agent A views trip histories for 30 different citizens in a day, flag for supervisor review. If Agent A views the same citizen 5 times in a day, flag.
- **Machine learning** on query patterns: agents should not be viewing trip histories for citizens they have no assigned case for. Cross-correlate case assignments with data access.

---

### Attack Vector #12 — Third-Party PSP Data Leakage (No Contractual Recourse Described)

**Severity:** 🟡 HIGH  
**Vector:** The PSP sees: card brand, last 4 digits, token reference, transaction amounts, transaction timestamps, and DOH as merchant. The acquirer sees DOH as merchant, merchant category (government toll), and aggregated transaction volumes. The card schemes see DOH's merchant category code. None of these are individually identifying, but **combined with pattern analysis**, the PSP could infer: how many DOH postpaid users there are, average trip value, peak billing times, and fleet vs. consumer billing volume.

**Exploit Scenario (PSP Breach):**
1. PSP's token vault is breached (not in DOH's control)
2. Attacker has access to token → PAN mapping for all DOH postpaid users
3. DOH's stored tokens can now be reversed to PANs — **the "no raw PAN" defense is shattered**
4. DOH has no independent ability to detect this breach
5. Disclosure timeline: the PSP notifies DOH only after they confirm the breach, which could be weeks

**Exploit Scenario (Data Sale):**
1. PSP sells anonymized transaction patterns to data brokers
2. "Government toll transactions in Bangkok, aggregated by time of day" is legal to sell
3. A data broker cross-references it with other datasets and re-identifies individual patterns
4. **DOH has no contractual right to stop this** unless explicitly written into the DPA

**Current Protection:** "PSP / Acquirer chosen by competitive selection." No mention of Data Processing Agreement (DPA) terms, no audit rights, no data residency requirements, no breach notification SLA.

**Recommended Fix:**
- **DPA terms must include**: (a) DOH retains ownership of all transaction and token data, (b) PSP cannot mine, aggregate, or sell DOH transaction data for any purpose, (c) breach notification within 24 hours of confirmed breach, (d) DOH has the right to audit PSP security controls annually, (e) data residency — all token and transaction data must remain in Thailand.
- **Technical controls**: the PSP should provide a "merchant isolation" guarantee that DOH's tokens are segregated from other merchants' tokens in the token vault.
- **Contractual exit plan**: what happens to tokens if DOH switches PSP? Can tokens be migrated? Are they PSP-proprietary? The proposal does not address **token portability** — a major lock-in risk.

---

## (c) PCI DSS Compliance Gaps

### Claimed: SAQ A (No cardholder data storage at DOH)

This is conditionally true IF:
- [x] DOH never touches raw PAN during provisioning (PSP-hosted form only)
- [x] DOH stores only PSP-issued tokens (not network tokens subject to de-tokenization)
- [x] No cardholder data appears in any DOH log (token references might count — need PSP attestation)

### Gaps the proposal does not address:

| Gap | PCI DSS Requirement | Risk |
|---|---|---|
| **Token reference in logs** | Requirement 3: Protect stored cardholder data | If application logs contain token references that can be linked to PANs via the PSP, DOH has cardholder data in logs. Solution: mask or strip. |
| **Encryption at rest (toll ledger)** | Requirement 7: Restrict access to cardholder data by business need-to-know | Even if no PAN is stored, the toll ledger contains account identifiers linked to payment methods. This is CDE-adjacent and should be encrypted. |
| **Key management** | Requirement 3.5: Document and implement key management processes | The proposal has zero references to encryption key management. Who holds keys? How are they rotated? HSM or software? |
| **Network segmentation** | Requirement 1: Install firewalls, segment CDE | The proposal does not describe a CDE boundary. Are toll lane operations in the same network segment as payment orchestration? They must be separated. |
| **Penetration testing** | Requirement 11: Regular penetration testing | No mention of when pen testing occurs, by whom, or how findings are remediated. |
| **Security awareness training** | Requirement 12: security awareness program | Call center agents handle trip data that is payment-adjacent. They must receive security training before POC go-live. |
| **Cardholder data discovery** | Requirement 11.1: Detect and alert on unexpected cardholder data | DOH needs a process to scan for accidentally stored cardholder data (e.g., a citizen pasting a card number in a free-text form field). |

**Bottom line:** SAQ A is achievable, but only with strict operational controls that are **not yet designed, let alone implemented**. The current architecture doc would not pass a SAQ A eligibility assessment.

---

## (d) Assumptions That Need Proof

The architect (Ginnie) has asserted the following without evidence. Each of these MUST be proven during the Discovery phase or the POC cannot proceed:

1. **"Tokenization eliminates PCI DSS scope for DOH."**
   → Needs PSP SAQ A attestation letter, not a design assertion. The PSP's compliance team must put this in writing with the specific tokenization model DOH will use.

2. **"Toll lane authentication is adequate."**
   → No authentication mechanism for lane → core is described. Claiming it's "secure enough" without specifying the protocol is not acceptable.

3. **"PSP will never be compromised in a way that affects DOH tokens."**
   → This is a faith-based assertion. DOH needs: PSP SOC 2 Type II report, penetration test results (within 12 months), and incident response runbook that specifically covers DOH's data.

4. **"The consent database is sufficiently protected."**
   → No backup strategy, no failover plan, no audit trail design. A "database" is not a "protected database."

5. **"Call center agents are trustworthy."**
   → Trust is not a security control. The architecture must assume a call center agent is compromised and design to limit blast radius.

6. **"Daily/threshold billing limits fraud exposure adequately."**
   → A fraudster can still cause ฿1,000–฿3,000 of damage per compromised card before the daily threshold triggers. At POC scale this is negligible; at national scale it's ฿1M+/month.

7. **"The reconciliation model catches 100% of data integrity issues."**
   → No test exists for sub-1% silent drops. No independent lane event counter stream is described.

8. **"PDPA compliance is achievable with DPIA alone."**
   → A DPIA identifies risks; it does not automatically mitigate them. The proposal does not describe what PDPA controls (data minimization, retention limits, subject access request process, breach notification) are actually in place.

---

## (e) What Would Make Me Change My Mind

I am skeptical by design, but I am not unreasonable. The following evidence would resolve my concerns and raise my score from 4.5/10 to 7+/10:

1. **Publish a security architecture diagram** — not a flow chart, but an actual architecture diagram showing: network boundaries (CDE vs. non-CDE), authentication protocols on every arrow, encryption in transit (TLS version, mTLS where applicable), and encryption at rest (algorithm, key management).

2. **Obtain a written SAQ A eligibility letter** from the chosen PSP, confirming DOH is completely out of PCI DSS scope under the specific tokenization model. This must be signed by the PSP's CISO or compliance officer.

3. **Demonstrate lane → core authentication in the sandbox** — not by a document review but by actually showing: (a) lane device presents an mTLS certificate, (b) core rejects unauthenticated events, (c) HMAC signature verification on every event.

4. **Publish the consent database architecture** — showing: append-only records, versioned schema, geo-replication plan, backup RPO/RTO, immutable audit log, and RBAC on consent modification.

5. **Publish the call center access control policy** — not in Thai and English in a slide deck, but as an implementable policy: role definitions, data masking rules, view-reason requirements, modify-first workflow prohibition, and anomaly detection thresholds.

6. **Commission an independent penetration test** after the sandbox but before the POC. Deliver the executive summary to the working group.

7. **Show the PSP contract's security annex** (redacted) — demonstrating: breach notification SLA ≤ 24 hours, annual audit rights, data residency requirements, transaction data usage restrictions, and exit/migration terms for token portability.

8. **Operationalize a lane event counter stream** — each lane reports a daily signed trip count that is independently verified against the billing pipeline. Demonstrate this working in the sandbox.

---

## (f) One Thing the Architect Got RIGHT

**Payment NOT in the lane critical path.**

This is the single best architectural decision in the proposal, and it deserves explicit acknowledgment. By keeping payment processing asynchronous from toll lane operation, the architect decouples two fundamentally different reliability requirements: (a) toll lanes must open a barrier in under 300ms, 99.999% of the time, 24/7/365 — this is a hard real-time system, and (b) payment processing can tolerate latency of seconds to hours, retries, queueing, and manual intervention.

This decision:
- Eliminates lane speed as a payment-related bottleneck
- Allows offline queueing during PSP outages
- Separates the resilience domain of lane operations from payment operations
- Enables the 6-failure-mode testing plan (which is also well-designed)

The architect understood that introducing payment into the lane critical path would have been a fatal design error — and avoided it cleanly. This is not a trivial insight; many real-world tolling systems (India's FASTag, Malaysia's TNG) have struggled with exactly this coupling. Getting it right from the start is genuinely commendable.

**Runner-up:** The 6-failure-mode testing plan is well-structured, particularly the "Reconciliation Breakage" test (Test 6) and the "Data Breach Tabletop" (Test 4). These show awareness of operational failure modes that many payment systems do not test until after a real incident. The fact that all 6 tests must pass before POC go-live is a strong gate.

---

*Prepared by Babigon, Security Skeptic / Technology Auditor  
For the Round 3 Debate — M-Pass Postpaid Security Attack Surface  
June 17, 2026*