Accounts with a purpose
Separate GBP, EUR and USD account views reconcile operating, reserve and settlement balances. Internal GBP transfers update both accounts while preserving total available cash.
Business treasury 2026
North
2026 / Treasury
- Field
- Business treasury
- Scope
- Product direction
Treasury workspace
Payment approvals
Cash allocation - Focus
- Clarity across the cash position
A treasury workspace that connects the cash position to the decisions behind it. Review supplier payments, release an approval and follow the updated balance into the account record. Allocate funds between operating, reserve and settlement accounts without losing sight of the total.
01
The cash position
Workspace
One treasury.
More perspective.
Review available cash, inspect a payment and follow the approval into the account record.
Product walkthrough · Illustrative data
- 01
Review before release
The supplier, funding account, reference and projected balance remain visible as a payment moves from the approval queue to confirmation.
- 02
Move cash, preserve the total
An internal allocation debits one account and credits another. It changes where the funds sit, without creating income or expense.
- 03
Trace each movement
Payment and allocation records stay linked to their accounts. Currency filters preserve the original denomination behind each balance.
The design brief
An operational perspective
Cash, approval queues and reserve allocation lead the screen. A persistent account rail and clear payment records turn the financial picture into a workspace people can actually use.
Calm, considered detail
Misty blue surfaces, precise figures and restrained compass geometry bring North's identity into an information-rich product. Focused review panels preserve the context behind each decision.
02
The working view
Treasury interface
Review, approve, reconcile
A payment opens into recipient details, funding account, reference and preparation history. Review the projected balance, acknowledge the details and release the sample payment into its completed record.
An auditable journey
Released payments leave the approval queue, reduce operating cash and create an activity entry. Filter the ledger by incoming, outgoing or internal movement and reopen each record.
03
A wider view, on a smaller screen
Responsive design
Engineering approach / Proposed architecture
A cash position you can trace.
North would combine bank balances, planned commitments and controlled payment instructions in one treasury workspace. Every figure would retain its account, currency, source and update time. Payment approvals and internal allocations would share a traceable record from request to confirmation.
- 01→
Collect the sources
Retrieve balances and transactions through bank-data integrations, with controlled statement imports where an API is unavailable.
- 02→
Normalise the records
Map each source to accounts, currencies and balance types. Retain provider references and flag missing or stale updates.
- 03→
Build the cash view
Group accounts by currency and add dated commitments in a separate forecast. Preserve the source behind every total.
- 04✓
Authorise the instruction
Check the operator’s role and approval policy, then send one reviewed instruction to the bank provider. Track its confirmation before changing the settled cash position.
Under the surface
The decisions
behind the experience.
Explore the system behaviour, integration choices and operational detail.
Available is not the same as booked
Keep available and current balances as separate fields, with the provider's meaning attached. Do not silently substitute one for the other or treat overdraft availability as owned cash. Show the last successful refresh beside the account.
A plan should not change the bank record
Store expected payments and internal transfers separately from imported transactions. Match them when actual movements arrive, so the forecast does not count the same commitment twice. Changes to an approved plan create a new reviewable version.
Totals need a common basis
Keep currency-specific totals as the primary view. A consolidated reporting view would use a named FX source and valuation time, with both the original and converted amounts available. Never silently add GBP, EUR and USD together.
Approval and release are separate controls
A production payment would retain its preparer, approver and approved version. Policy could require a second person above a defined threshold. Recheck permissions and available funds at release, reuse the same provider request key on retries and retain pending status while the bank outcome is uncertain.
A possible production stack
- Treasury workspaceNext.js + TypeScript
- Share the cash overview, account drill-down and approval screens, with server-side checks for organisation and role access.
- Bank connectivity & paymentsProvider-specific bank adapters
- Retrieve balances and transactions, and submit supported payment instructions through the appropriate bank connection. Data access and payment initiation would be separately authorised and scoped.
- Cash & planning dataPostgreSQL
- Keep exact amounts, source identifiers, refresh times and versioned commitments connected to the same account model.
- Refresh & importsTypeScript background workers
- Fetch updates within provider limits, deduplicate imported records and retry failed refreshes while retaining the last known state.
Your next fintech product
A clearer view of your treasury.
Tell us about your customers, workflows and technical requirements. We’ll shape the right approach together.
