บทที่ 16 · Part 3 — Bound Models and Relationships
Fintech Domain Landscape
ทดสอบ candidate contexts รอบ Customer Intent, Payment Execution, Ledger, Risk, Balance และ Reconciliation
Fintech Domain Landscape
ชื่อ Wallet, Payment, Ledger, Risk และ Reconciliation ฟังเหมือน boundary มาตรฐาน แต่บริษัทหนึ่ง อาจให้ provider ถือ funds อีกบริษัทเป็น stored-value operator และอีกบริษัทเพียงแสดงบัญชีธนาคาร การคัดลอก Context Map จาก Fintech รายอื่นจึงอันตราย บทนี้ใช้ landscape เป็นชุด hypotheses ให้ผู้เรียนทดสอบด้วย scenarios และ authority
จบบทนี้คุณจะ
สร้าง candidate Fintech landscape ที่แยก customer intent, eligibility, funds authority, execution, financial records, reconciliation และ display อธิบายคำว่า Payment/Balance/Account ต่าง context และ trace transfer journey โดยไม่อ้างว่า map นี้ใช้ได้ทุกบริษัท
Candidate Concerns
| Concern | Decision/knowledge | คำที่ต้องท้าทาย |
|---|---|---|
| Customer Intent | ลูกค้าขอส่งอะไร ยืนยัน/ยกเลิกเมื่อใด | transfer, cancel, beneficiary |
| Eligibility/Risk | policy ใดอนุญาต ณ เวลาใด | verified, eligible, approved |
| Funds Authority | เงินส่วนใดใช้ได้/ถูก reserve | balance, available, hold |
| Payment Execution | provider/network ทำอะไรและรู้อะไร | accepted, captured, failed, unknown |
| Ledger/Accounting | financial facts และ corrections | account, entry, post, reverse |
| Reconciliation | records ตรงกันหรือไม่และใครซ่อม | matched, exception, resolved |
| Customer Display | อธิบายสถานะ/ยอดอย่างไร | pending, complete, displayed balance |
แต่ละ concern อาจเป็น Subdomain, Context, module หรือเพียง concept ขึ้นกับ evidence
Money Transfer Journey
Diagram ไม่แสดง network topology และไม่บอกว่า events เป็น messages จุดสำคัญคือ facts/decisions มี authority ต่างกัน
Payment ไม่เท่ากับ Ledger
Payment Execution สนใจ provider attempts, protocols, outcome evidence และ retries Ledger สนใจ
financial entries/transactions และ accounting invariants provider succeeded อาจเป็น input ให้ posting
แต่ไม่ใช่ entry เอง
อย่าสร้าง ledger rule จาก vendor docs เพียงอย่างเดียว ต้องมี accounting/domain owner และ audit source ที่เกี่ยวกับบริษัท ก่อนเพิ่ม prescriptive double-entry/reversal design
Balance หลายความหมาย
Monzo first-party case แสดงว่า balance definitions/time axes ต่างกันทำให้ systems ให้คำตอบไม่ตรง เป็น evidence ว่า named definitions สำคัญ แต่ model ของ Monzo ไม่ใช่ recipe ของเรา
แยก candidate terms:
- Posted Balance — derive จาก posted financial facts
- Available Funds — amount ที่ policy อนุญาตให้ใช้ ณ decision time
- Displayed Balance — projection สำหรับ UI พร้อม freshness
- Settlement Position — amount กับ external party ตาม report/cutoff
Display Path ห้ามกลายเป็น Decision Path
Portal cache อาจแสดงข้อมูลเก่าได้ตาม contract แต่ Reserve Funds ต้องให้ Funds Authority ตรวจ
authoritative state/invariant ภายใต้ concurrency ที่เหมาะสม ห้ามใช้ชื่อ balance เดียวเป็นเหตุผล
Risk Decision มี Policy Version
Risk ไม่ใช่ boolean isVerified ทั่วระบบ Decision อาจมี subject, purpose, evidence, policy version,
jurisdiction, decidedAt, validity และ reason visibility คำว่า approved ของ Onboarding ไม่จำเป็นต้อง
อนุญาตทุก transfer
Threshold/retention/KYC rules ต้องมาจาก Risk/Compliance/regulator owner พร้อม source/date
Reconciliation เป็น Business Capability
Reconciliation ไม่ใช่ cron job ที่ “แก้ข้อมูลให้ตรง” มันมี:
- comparison scope/cutoff
- internal/external records
- exception identity/classification
- evidence request
- correction/compensation authority
- closure criteria และ unresolved backlog
เมื่อ business scale/risk สูง มันอาจเป็น Supporting หรือ Core capability ตาม strategy
Company Variants
| Context | Small business | Scale-up | Corporate/regulated |
|---|---|---|---|
| Provider | รายเดียวและ conform/ACL เล็ก | หลายราย, routing/reconciliation | หลาย rails/entities/contracts |
| Teams | ทีมเดียวหลาย model boundaries | ownership แยก coarse contexts | หลาย units/jurisdictions/legacy |
| Deployment | modular application | services เมื่อ evidence | mixed legacy, modules, services |
| Governance | glossary/examples ใกล้ code | context registry/contracts | Published Language, policy provenance |
semantic distinctions ยังสำคัญทุกขนาด แต่ implementation/ceremony ต่างกัน
แบบฝึกปฏิบัติ: Landscape Hypothesis
ส่งมอบ:
- glossary ของ Payment, Transfer, Account, Balance, Success, Reversal
- candidate Subdomains พร้อม strategic type
- Context Map 2 alternatives
- authority table: intent/risk/funds/execution/ledger/display/reconcile
- replay unknown outcome และ late settlement scenarios
- company variants 3 แบบ
- open questions พร้อม business/finance/risk owners
รายการตรวจสอบ
- Landscape เป็น hypothesis ไม่ใช่ Fintech standard
- Customer intent แยกจาก provider execution
- Execution fact แยกจาก ledger posting
- Funds decision แยกจาก display projection
- Risk decision มี owner/version/validity
- Reconciliation มี lifecycle/authority
- Company context เปลี่ยน implementation ไม่ลบ semantics
สรุปบทนี้
Fintech landscape ที่ใช้งานได้แยก language และ authority ของ intent, risk, funds, execution, financial records, display และ reconciliation แต่ boundary จริงต้องค้นพบจาก strategy/policy/ownership ของบริษัท ไม่ใช่คัดลอก service names ของ vendor
อ่านเพิ่มเติม
- Stripe Payment Intents — vendor-specific lifecycle evidence
- Stripe Reporting and Reconciliation
- Monzo: How We Calculate Balances
- Adyen Architecture Decisions — first-party context, not universal recipe