Customer Portal &
Backoffice Scope

Payin flow

Partner webhook → match to virtual account → screen the sender → credit entries → notify. Incoming money becomes spendable on a timetable matched to how reversible that payment type is — instantly for irreversible rails, slower for recallable ones, faster as a client earns history.

Unmatched payins go to an ops queue rather than being guessed at. Guessing at attribution is how money ends up in the wrong client's balance.

Failure handling

Every rails call is idempotency-keyed, because the failure mode that matters isn't "payment failed" — it's "we don't know if it succeeded."

Timeouts reconcile rather than retry blindly. Webhooks are signature-verified and replay-safe. Anything unresolvable becomes an ops task — never a silent failure.

Blocking — licensing

What licence does Glob hold, and where?

Holding client funds in a pooled account is a regulated activity in every jurisdiction the site names (APAC, Europe, UK, Middle East, Americas). This determines safeguarding rules, reporting duties, and whether Glob is principal or agent of the partner. It changes the ledger's obligations, not just the paperwork. Answer needed before P1 build starts.

Blocking — partner

Which partner(s), and is the contract signed?

The rails adapter is designed against a real API, and partners differ wildly in what they expose — webhook reliability, virtual-account support, statement format, settlement timing. Building against a hypothetical partner produces an abstraction that fits none.

Scope risk

Corridors and currencies at launch

"Cross-border" is not a scope. Each corridor brings its own beneficiary fields, purpose codes, local-rail quirks, and cut-offs. Three named corridors is a project; "global" is a programme. I'd propose naming the launch corridors explicitly in the plan.

Scope risk

Screening vendor — buy, don't build

Sanctions/PEP list management is a subscription (ComplyAdvantage, Dow Jones, Refinitiv), not a feature. We build the queue and the case workflow; the vendor supplies lists and match scoring. Budget and contract lead-time belong in P1 planning.

Deferred deliberately

Public API pushed to P3

Epay exposes a 开发者 section; Glob's marketing does not mention an API. A public API is a product with its own versioning, sandbox, docs, key management, and support burden — and once external code depends on it, the schema stops being ours to change. Deferring until the internal model has settled is the cheaper order.

Deferred deliberately

No crypto / virtual assets

Epay's 虚拟资产 module is out of scope. It would add custody, on-chain monitoring, travel-rule compliance, and hot-wallet operations — roughly doubling the compliance surface for a capability Glob's marketing doesn't currently sell.

Blocking — staffing

A named MLRO / compliance officer

Building our own rules engine means Glob authors its rule book and defends it to the regulator — thresholds, dismissal sign-offs, SAR filings. In most regimes a named officer is a licensing requirement, not a nice-to-have. The hire gates P1 go-live, and they should co-design the rule parameters, not inherit them afterward.

Policy consequence

Hold-on-any-flag has a cost we accept knowingly

Decided: every fired rule holds the payment until compliance clears it. The cost is that false positives block legitimate client money — so triage SLA becomes a customer-experience metric, staffing the queue is a launch requirement, no rule ships without backtesting its hold volume, and hold→clear time is monitored like uptime.