Glob Payment

Scope Proposal

Proposal — Scope Definition

Customer Portal &
Backoffice Scope

Glob Payment today is a marketing site with a Request Access button and no product behind it. This document defines the product that button should lead to: a corporate portal for moving money in and out across borders, and the operations console that makes it safe to run.

Ref: payment.weglob.net UI ref: Epay 易派 Status: For review

Scope

Transfers + Collections

Money moves both directions

Rails

Partner API

Pooled account, our own ledger

Controls

Maker–checker

Threshold-driven, from v1

Onboarding

KYB, invite-only

No public self-signup

§01 — Summary

What we're building

From marketing claim to product surface

The four pillars on payment.weglob.net each imply real screens. Notably, the fourth pillar — Operational Risk & Reconciliation — is sold to clients but is almost entirely a backoffice function. That asymmetry is the main reason the backoffice is not a smaller project than the portal.

Pillar 01

Business Payment Accounts

→ Multi-currency balances, team & roles, access controls, statements

Pillar 02

Domestic & Cross-Border Transfers

→ Payouts, beneficiaries, FX conversion, approvals, tracking

Pillar 03

Merchant & Platform Support

→ Virtual accounts, payment links, settlement, payer reconciliation

Pillar 04 — mostly backoffice

Operational Risk & Reconciliation

→ Screening queues, case management, partner recon, break resolution

Customer portal

28

screens across 9 modules

Backoffice

31

screens across 7 modules

See both menu trees

Indicative timeline

3 phases

first client onboarded at end of P1

§02 — Architecture

One ledger, two portals

The load-bearing decision

The ledger is double-entry and append-only. Balances are never stored as a mutable number — they are derived from entries. Nothing writes a balance; everything writes entries.

Every event — a payin landing, a payout leaving, an FX conversion, a fee, a reversal — is a balanced set of entries. A correction is a new reversing entry, never an edit. This gives provable history, and it makes the reconciliation question "do our books match the partner's?" answerable at any timestamp rather than approximately. Because Glob holds client funds in a pooled account, our ledger — not the bank statement — is what the customer sees. If it can drift, it will.

Identity

Identity & Access

Clients, users, roles, KYB state, approval thresholds

Core

Ledger

Accounts, entries, balances, holds. Knows nothing about banks or customers.

Flow

Money Movement

Payment & collection state machines, beneficiaries, FX quotes

Rails

Rails Adapter

One interface per partner. All partner ugliness lives here and nowhere else.

Risk

Compliance

Sanctions screening, transaction review, case management

Why the rails boundary matters most. One or two partners today — but partners get replaced, and new corridors arrive by adding partners. If partner-specific handling leaks into money movement, every new corridor becomes surgery on the payment engine. This boundary is cheap to hold now and expensive to retrofit later.

Payout flow — two distinct review gates

01

Create

Maker drafts payment

02 — gate

Client approval

Checker, if over threshold

03 — gate

Glob screening

Sanctions + rules

04

Hold funds

Ledger reserves balance

05

Submit to rails

Idempotency-keyed

06

Settle

Webhook → entries, hold released

Payin flow

Partner webhook → match to virtual account → screen the sender → credit entries → notify.

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.

A note on status vocabulary. The Epay reference shows a single 审核中 (under review) counter. Our architecture has two distinct review stages — the client's own approver, and Glob's compliance screening. The portal should surface these as different states, because "waiting on my colleague" and "waiting on Glob" are entirely different problems for the customer, and collapsing them generates support tickets.

§03 — Customer Portal

app.weglob.net

Proposed navigation

Overview
Accounts
Send money
Receive money
Convert
Beneficiaries
Statements
Compliance
Settings

Acme Trading Ltd

GLB-2847-001

Send / Receive split as top-level items rather than Epay's product-name grouping — clients think in directions of money, not product SKUs.

01

Overview

P1

Dashboard

Total balance in reporting currency, per-currency tiles, recent activity, items awaiting your approval

Action centre

Payments needing approval, expiring documents, compliance requests for information

Banking calendar

Holiday impact on value dates per corridor — borrowed from Epay's 节假日 panel; it exists because cut-offs are real

02

Accounts

P1

Balances

Per-currency: available, pending, on hold — three numbers, never one

Account detail

Ledger view with running balance, filters, entry drill-down to source event

Transactions

Unified in/out list, saved views, CSV + PDF export

03

Send money

core
P1

New payment

Guided flow: beneficiary → amount & currency → purpose code → quote → review. Shows fees, FX rate, and expected arrival before commit

Bulk upload

CSV batch with per-row validation and a dry-run before submit

Approvals inbox

Checker queue: approve / reject with reason. Maker cannot approve own payment — enforced server-side, not hidden in UI

Payment tracking

Status timeline with the two review gates shown distinctly; proof of payment on settle

Scheduled & recurring

Deferred to P3

04

Receive money

core
P2

Virtual accounts

Named account details per currency the client can hand to their own payers

Payment links

Hosted one-off request-for-payment page

Incoming payments

Payer, reference, matched invoice, settlement status

Settlement

Batch view: gross → fees → net credited, with the ledger entries behind each

05

Convert (FX)

P1

Quote & convert

Time-boxed quote with visible countdown, locked rate, explicit margin disclosure

Conversion history

Rate achieved and margin applied, per conversion

06

Beneficiaries

P1

Directory

Per-corridor field requirements (IBAN / SWIFT / ACH / local) driven by config, not hardcoded forms

Add / edit + approval

New beneficiary is itself an approval event — the most common fraud vector is a quietly edited bank account

07

Statements & Compliance

P1

Statements

Period statements, PDF + CSV, per currency

Documents

KYB document vault with expiry tracking and re-upload prompts

Requests for information

Compliance asks a question about a payment; client answers in-portal with an audit trail. Replaces the email thread this would otherwise become.

08

Settings

P1

Team & roles

Invite users; roles: Admin / Maker / Checker / Viewer

Approval policy

Thresholds per currency; always-approve rules (e.g. new beneficiary). Default: unlimited threshold = effectively off

Security

MFA (mandatory), session policy, IP allowlist, audit log

API keys & webhooks

Deferred to P3 — see Risks

§04 — Backoffice

ops.weglob.net

The most commonly under-planned part of a payments build. With partner-API rails, ops staff aren't in the payment path for happy flows — but they own every unhappy one: the payin nobody can attribute, the payout the partner accepted and then bounced, the balance that doesn't tie out. Under-building here doesn't slow the launch; it shows up three months later as staff working from spreadsheets and a ledger nobody trusts.

B1

Client management

P1

Client directory

All corporate clients, status, risk rating, balances

KYB onboarding queue

Request Access → entity, UBOs, directors, docs → approve / decline / request more. This is what the marketing CTA feeds.

Client profile

Entity tree, documents, users, limits, corridor permissions, notes

Periodic review

Scheduled re-KYB by risk tier, document expiry chasing

Impersonate / view-as

Read-only, consent-gated, fully audited — for support without screen-sharing

B2

Compliance

core
P1

Screening queue

Sanctions / PEP / adverse-media hits with match scores; clear or escalate. Payment is held, never silently passed

Transaction review

Rule-triggered review: thresholds, velocity, new corridor, structuring patterns

Case management

Investigation notes, evidence, RFI to client, outcome, four-eyes sign-off

Rules configuration

Thresholds and jurisdiction blocks editable by compliance, not by deploy

Regulatory reporting

SAR/STR drafting and export

B3

Payment operations

core
P1

Payment explorer

Every payment across all clients; search by any identifier a client might quote on the phone

Exception queue

Failed, returned, bounced, stuck-in-flight. Every item has an owner and an action

Unmatched payins

Money arrived, attribution unclear → manual match or return to sender

Repair & resubmit

Fix beneficiary details and retry without re-entering the whole payment

Manual adjustment

Reversing entries only. Reason mandatory, four-eyes mandatory, immutable. The single most dangerous screen in the system.

B4

Treasury & reconciliation

core
P1

Pooled account position

Per currency, per partner: what the bank says we hold

Safeguarding check

Sum of client balances vs. pooled account. These must tie. Continuously. A break here is a regulatory event, not a bug

Partner reconciliation

Auto-match partner statement against our ledger; surface only the breaks

Break resolution

Ageing, assignment, root-cause tagging so the same break stops recurring

Liquidity monitor

Balance alerts per currency before payouts start failing for lack of funds

FX position

Net exposure by currency, margin earned, hedging hand-off

B5

Pricing & billing

P2

Fee schedules

Per client, per corridor, per method; effective-dated so history stays reproducible

FX margin config

Spread by client tier and currency pair

Revenue reporting

Fee + FX margin by client and corridor

B6

Platform administration

P1

Staff & roles

Ops / Compliance / Treasury / Support / Admin, least-privilege by default

Audit log

Every staff action, immutable, searchable, exportable for auditors

Corridor & partner config

Enable corridors, routing rules, cut-off times, banking calendars

Partner health

API status, webhook lag, failure rates — know before the client calls

§05 — Phasing

Build order

PHASE 1

Money out, safely

First client live

Ledger, KYB onboarding, multi-currency balances, payouts with maker–checker, FX conversion, beneficiaries, statements. Backoffice: client management, screening, payment ops, treasury & recon, admin. Ends with a real client funding an account and sending a real payment.

Ledger KYB Payouts Maker–checker FX Screening Recon
PHASE 2

Money in

All four pillars true

Virtual accounts, payment links, incoming payment attribution, settlement batches, payer screening. Backoffice: unmatched payin queue, settlement ops, pricing & billing. Reuses the entire P1 backbone — this is why collections is cheap after P1 and expensive alongside it.

Virtual accounts Payment links Settlement Billing
PHASE 3

Scale & self-serve

Public API + webhooks + sandbox, scheduled and recurring payments, advanced reporting, additional partners and corridors, SSO.

Public API Webhooks Recurring SSO

§06 — Risks & open questions

What could bite

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.

Decisions needed to proceed

01

Licence position & jurisdictions at launch

02

Named banking / PSP partner(s)

03

Launch corridors and currencies (explicit list)

04

Screening vendor selection

05

Brand direction — inherit marketing site, or new system

06

Languages at launch (EN only, or EN + 中文)