The HBF platform is a payment intermediary — a system that receives money from clients and executes payments to third parties on their behalf, in two directions: outbound (pay on behalf) and inbound (receive on behalf). Building it required making clear decisions about every layer of the stack. This is a technical account of the most consequential ones.
The architecture in one sentence
Express and TypeScript on Node.js, PostgreSQL for persistence, Wise API for international payment execution, Stripe for domestic card payments, AWS S3 for document storage, SendGrid for transactional email, and a custom AI risk engine that scores every transaction before a human reviews it.
Why Wise won over Stripe for cross-border execution
Stripe Connect is the more familiar choice for developers. It is excellent for marketplace payments and split payments between parties on the same platform. But for a payment intermediary that needs to execute to arbitrary bank accounts internationally — with full quote-then-execute flow, currency conversion at mid-market rates, and recipient bank validation — Wise's three-step API is significantly more appropriate.
The Wise flow is: create a quote (specifying currency pair and amount, receiving back a rate and fee breakdown), create a transfer (attaching the quote to a validated recipient account), and fund the transfer (triggering execution from the source account). This maps precisely to how HBF operates — quote presented to client, client approves and pays, HBF executes — in a way that Stripe's architecture does not naturally support.
The dual-approval requirement
Any transaction at or above £10,000 requires two separate staff members to authorise before execution. This is not a UI feature — it is enforced at the API level in the execute-payment endpoint. The first approval creates an approval record. The endpoint checks for a second, different approver before executing. A single staff member cannot approve and execute a high-value transaction regardless of their role level.
The AI risk engine
The risk engine scores seven factors: transaction amount relative to client history, document authenticity indicators, recipient country risk, stated purpose consistency, client KYC status, sanctions screening result (HMT, OFAC, UN lists), and velocity — the number of transactions in a rolling period. It returns a score (green, amber, red) and a recommended payment route. It runs asynchronously after request creation. The client gets their reference number immediately; the risk score populates in the admin queue within seconds. The frontend must handle the loading state — no blocking on risk scoring.