# Babigon — Payment Gateway & Legal Expert — Technical & Legal Review **Reviewer:** Babigon, Payment System Architect + Regulatory Legal Counsel **Role:** Payment Gateway System Provider + Legal Expert **Date:** 17 June 2026 **Subject:** Easy Pass / M-Pass Postpaid Enablement — Technical Architecture, Legal, and Payment Compliance Review --- ## ✅ What Works Well — Technical & Legal ### 1. Architecture Separation Is Correctly Emphasized The repeated statement "Payment is NOT in the toll lane critical path" is both technically accurate and legally important. The lane records trip events; payment processing happens asynchronously in the back office. This distinction eliminates any argument that postpaid tolling will slow down traffic. **This is the single most important technical claim on the entire site — and it's prominent.** ### 2. Card Data Handling Is Legally Sound The architecture correctly places card data handling in the PSP/acquirer layer, with DOH storing only token references, not raw PANs or CVVs. This aligns with: - PCI DSS requirements (SAQ A for token-only merchants) - PDPA data minimization principles - Bank of Thailand payment system oversight expectations - Card scheme stored-credential rules (Visa MIT, Mastercard UCOF) ### 3. Consent Evidence Model Is Comprehensive The minimum fields listed for consent evidence (customer ID, vehicle/tag/plate, token reference not PAN, consent version, timestamp, billing model, cap, terms version, withdrawal method, privacy notice version) are thorough. This will survive a PDPA audit AND a card scheme dispute review. ### 4. Reconciliation Layers Are Finance-Ready The 8-layer reconciliation model (event → priced trip → billing ledger → payment attempt → PSP response → settlement file → bank credit → revenue accounting) demonstrates serious payment operations thinking. Most POC proposals skip this entirely. Finance/audit will appreciate this. ### 5. Stop/Pause Criteria Cover The Right Triggers Legal authority blocker, payment success below threshold, unpaid exposure exceeding cap, complaint rate threshold, reconciliation variance, critical PDPA/cyber finding, call center SLA failure — these are the right operational gates. They protect the project from becoming an uncontrolled liability. ### 6. Bilingual Legal Terminology Is Correct Terms like "stored credential," "merchant-initiated transaction (MIT)," "unscheduled credential-on-file (UCOF)," and "customer-initiated transaction (CIT)" are used accurately. The Thai translations are faithful enough for regulatory review. --- ## ⚠️ Technical & Legal Risks — Must Address ### 1. 🔴 CRITICAL: Missing Regulatory Gate — BOT Consultation **Problem:** The page mentions "BOT liaison" in governance but does not explicitly call out that Bank of Thailand consultation is a GATE to live POC, not just advisory. Under the Payment Systems Act B.E. 2560, certain payment activities may trigger notification or approval requirements. Card-on-file toll billing is novel in Thailand and needs explicit BOT positioning. **Recommendation:** Add a dedicated regulatory gate card: > **Regulatory Gate:** BOT payment system oversight consultation must confirm whether postpaid toll billing via stored credential is classified as: (a) existing toll collection authority — no new license needed, (b) regulated payment service requiring notification, or (c) regulated payment service requiring BOT approval. This gate must pass before live POC. > > **ประตู Regulatory:** ต้องได้รับคำปรึกษาจาก BOT (ธปท.) ว่า postpaid toll billing via stored credential จัดอยู่ในประเภทใด: (ก) เป็นอำนาจเก็บค่าผ่านทางที่มีอยู่แล้ว, (ข) เป็น regulated payment service ที่ต้องแจ้ง BOT, หรือ (ค) เป็น regulated payment service ที่ต้องขออนุมัติ BOT — ต้องผ่านประตูนี้ก่อน live POC ### 2. 🟡 HIGH: Card Scheme Rules — MIT/UCOF Eligibility **Problem:** The page uses MIT/UCOF terminology correctly but doesn't address the CRITICAL distinction: not all acquirers in Thailand support unscheduled credential-on-file for government toll operators. Some acquirers restrict MIT to subscription/utility categories. Most Thai acquirers have limited UCOF experience outside e-commerce subscriptions. **Recommendation:** Add to the Discovery/Sandbox section: > **Acquirer Compatibility Gate:** During Discovery, confirm with at least 2 qualified PSP/acquirers in Thailand that: > - Their acquiring license covers government toll operators > - Their scheme registration supports MIT/UCOF for variable-amount toll billing > - Their risk team approves the toll billing merchant category > - Settlement cycle meets government revenue timing requirements > - Chargeback/reversal processes are documented and tested ### 3. 🟡 HIGH: PDPA — Trip Data Sensitivity Classification **Problem:** The page says "toll trip data should be treated as sensitive-by-context" — this is a good operational stance but legally understated. The PDPA does not classify travel patterns as "sensitive personal data" under Section 26. However, combined with other data points (time, location, frequency), trip data CAN reveal: - Religious practice (temple/church/mosque visitation patterns) - Political activity (protest location proximity) - Health conditions (hospital visit frequency) - Personal relationships (residential visitation patterns) This needs stronger language. **Recommendation:** Strengthen the PDPA section: > **PDPA Position:** While toll trip data is not categorically "sensitive personal data" under PDPA Section 26, the project shall treat it as **sensitive-by-analytics-risk** because combined trip data can infer protected characteristics. Controls shall include: data minimization by default, automatic masking after billing cycle, strict retention schedule, prohibition on behavioral analytics without separate consent, and mandatory DPIA before any data-sharing or analytics use case. ### 4. 🟡 HIGH: Failed Payment Collection — Legal Authority Gap **Problem:** The POC assumes failed payments can be retried and eventually collected. But under current Thai toll law: who has legal authority to pursue payment collection outside the toll lane? Can DOH suspend postpaid privilege while maintaining road access via prepaid? Is there a legal collection pathway that doesn't require court action for small amounts? **Recommendation:** Add a specific legal discovery question: > **Legal Discovery Must Confirm:** (1) DOH authority to pursue payment collection for tolls used but not paid, (2) whether suspension of postpaid privilege is permitted while other payment methods remain available, (3) whether unpaid toll amounts can be aggregated across trips for collection, (4) whether DOH can contract a third-party collection agent, and (5) minimum amount/aging thresholds for legal collection action. ### 5. 🟡 MEDIUM: Chargeback Liability — Who Bears The Loss? **Problem:** In a MIT/UCOF model, chargebacks are a reality. The website mentions chargeback tracking but doesn't clarify liability allocation. If a cardholder disputes a toll charge 45 days later, who eats the loss — DOH as the merchant of record, or PSP under a guarantee model? Most Thai acquirers will NOT guarantee MIT/UCOF chargebacks for government toll operators without significant volume commitment. **Recommendation:** Add to POC Financial Controls: > **Chargeback Liability Model:** Discovery must confirm the chargeback liability allocation between DOH and PSP: > - Fraud chargebacks (stolen card used): typically PSP/acquirer liability under 3DS > - Service dispute chargebacks (customer disputes toll amount): typically merchant (DOH) liability > - Processing error chargebacks: liable party depends on error origin > - POC must have a pre-funded chargeback reserve or PSP guarantee model > - Monthly chargeback rate target: ≤0.1% of transactions (card scheme threshold is 0.9%) ### 6. 🟡 MEDIUM: MDR/Fee Economics — Missing the Real Cost Story **Problem:** The website says "no visible consumer surcharge during POC" which is politically safe, but doesn't explain how MDR (1.5-2.5% in Thailand for card-not-present) will be absorbed. At 2% MDR on a ฿50 toll, that's ฿1 per transaction — which IS the proposed service fee. The economics only work if aggregation (Model B: daily/threshold) reduces transaction count significantly. **Recommendation:** Add explicit economics: > **MDR Economics — Why Aggregation Is Critical:** > | Billing Model | Monthly Trips | Transactions/Month | Est. MDR Cost | > |---|---|---|---| > | Per-trip charge | 60 trips | 60 | ฿60 (฿1/trip at 2% of ฿50) | > | Daily aggregation | 60 trips | 30 | ฿30 | > | Threshold (฿500) | 60 trips | ~6 | ฿6 | > > **Conclusion:** Without aggregation, MDR alone consumes the proposed service fee. The POC MUST validate aggregation economics with real transaction data. ### 7. 🟢 LOW: Token Lifecycle Management — Not Addressed The page doesn't address what happens when a card expires, is reissued, or is cancelled. PSP tokenization platforms (Visa VTS, Mastercard MDES) handle much of this automatically through account updater services, but the POC should explicitly confirm this capability with the selected PSP. ### 8. 🟢 LOW: Cross-Border Card Compatibility For the foreigner/rental use case: not all foreign cards support MIT/UCOF. European cards under PSD2/SCA may require stronger authentication for the initial CIT setup. Some Asian card issuers may decline MIT from Thai merchants. The POC should test with a representative sample of foreign card BINs (US, EU, CN, JP, ASEAN). --- ## Legal Compliance Checklist — Before Live POC | # | Requirement | Status on Site | Recommendation | |---|---|---|---| | 1 | DOH postpaid toll collection authority | Mentioned as gate | Add explicit legal memo requirement | | 2 | BOT Payment Systems Act consultation | Mentioned lightly | **Upgrade to explicit regulatory gate** | | 3 | PDPA/DPIA | Mentioned | Add analytics-risk language | | 4 | PCI DSS compliance path | Implied via PSP | Add explicit SAQ A path | | 5 | Card scheme stored-credential approval | Not mentioned | **Add Discovery gate** | | 6 | Consumer contract terms enforceability | Consent fields listed | Add consumer protection law review | | 7 | Cross-border data transfer (foreign cards) | Not mentioned | Add if foreign PSP used | | 8 | Government revenue accounting standards | Not mentioned | Finance gate should cover | | 9 | Procurement integrity / no lock-in | Addressed | Strong | | 10 | Dispute resolution mechanism / ADR | Not mentioned | Add to Citizen Protection section | --- ## Overall Assessment **Technical accuracy:** ⭐⭐⭐⭐ (good — architecture is correct, payment flow is accurate, some acquirer-specific details missing) **Legal readiness:** ⭐⭐⭐ (foundation is solid, missing BOT gate and explicit legal authority framing) **Payment compliance:** ⭐⭐⭐ (MIT/UCOF classification correct, missing acquirer compatibility gate and chargeback liability model) **Finance/Reconciliation:** ⭐⭐⭐⭐⭐ (excellent — 8-layer model is best practice) **Verdict:** The technical core is strong but under-lawyered in three critical areas: BOT regulatory classification, acquirer UCOF compatibility, and chargeback liability. These are NOT blockers for Discovery — they ARE the purpose of Discovery. But the page should explicitly list them as Discovery deliverables so that legal/payment reviewers see they have been anticipated. **My recommendation:** Add the BOT regulatory gate, the acquirer compatibility gate, and the chargeback liability model as explicit Discovery deliverables. These additions will protect the project from legal/payment objections during the approval process. --- *Babigon · Payment Gateway & Legal Expert · Review completed 17 June 2026*