The partner portal

The partner portal is a web application for the people in your organisation who are not integrating: finance, operations, support. It shows the same accounts, transactions, transfers, virtual accounts and webhook deliveries the API acts on, read-only, with two operational buttons and a team page. Nothing in it changes a payment, a client or a secret.

Getting in

• Invitation only. The bank invites your first administrator; that administrator invites colleagues from the Team page. Each person sets a password from the invitation.
• Two-factor authentication is mandatory. A person who has not enrolled is confined to enrolment until they have. Enrolment uses an authenticator app and issues recovery codes; both are managed from Settings.
• One person, several organisations. A user can belong to more than one corporate with a different role in each, and switches between them in the portal. The role on the active organisation is the one that applies.
• Six months of history. Every dated page covers at most the last six months, and a single request spans at most six months. Older records are held by the bank; ask your relationship manager.
• Sessions. The API behind the portal lists a user’s live sessions and lets them sign one out, which revokes that device’s refresh token family rather than one page.

Sessions and password change

The session list, single-session sign-out and password change are served by the portal’s API (/api/portal/me/sessions, /api/portal/me/change-password), but the current Settings page does not yet expose them; its own source marks both as still to come. Until they land, a forgotten password is reset from the sign-in page and a suspect session is ended by asking the bank to suspend the login.

Roles

A role is per organisation, and the roles differ along two lines rather than one ladder: whether balances are shown, and whether the accounts surface exists at all.

Role	Balances	Accounts and statements	Re-send a notification	Manage the team
ADMIN	Yes	Yes	Yes	Yes
FINANCE	Yes	Yes	No	No
OPS	No	No access	Yes	No
VIEWER	No	Yes, without figures	No	No

A balance withheld from a role is omitted by the server, not hidden by the page: a VIEWER’s export cannot carry a figure their screen did not show. “Re-send a notification” covers both a failed webhook delivery and a remote virtual-account band’s callback.

The pages

Overview. The first page: your position per currency across every account the session reaches (available, ledger and holds), money in and out over the last thirty days or a window you choose, a daily series, and anything needing attention, such as transfers under investigation. A second tier shows where the money went (payments, fees, tax and stamp duty as their own slices), how transfers ended, and what each virtual-account band took in.

Accounts. Every account the organisation holds, with balances for ADMIN and FINANCE, and for each a statement over a date window with export. OPS does not see this page at all.

Transactions. One register across everything the organisation can see, including its agents’ accounts. A date window is required; filters for account, transaction type, channel, amount range and free text are applied server-side. Each row opens to the posting’s metadata: counterparty, bill token, session id, whatever the transaction carries.

Interbank transfers. Every NIP transfer, inward and outward, in the five customer-facing states (PROCESSING, COMPLETED, FAILED, REVERSED, UNDER_INVESTIGATION) with your reference, the counterparty and the session id. A transfer opens to its timeline of debited, completed and returned moments and, when it failed or was returned, the NIBSS response code with its published meaning. A completed outward transfer has a printable receipt. The register exports to CSV or XLSX. See Interbank transfer.

Virtual accounts. The bands your organisation owns (its own and its agents’), with two sub-pages: Issued, the numbers allocated from each band, and Inflows, every payment received on them over a window, with totals, a detail view naming the virtual account the payer used, export, and a re-send button for a failed notification (ADMIN and OPS). Settlement detail is deliberately not shown here; see Virtual accounts.

Webhooks. Each endpoint your organisation has registered, its delivery history, and each delivery’s payload as the portal is willing to show it (sensitive fields redacted). ADMIN and OPS can retry one delivery at a time. There is no create, edit, disable or secret rotation here: those are arranged with the bank. See Delivery and retries.

Agents. For aggregators only, and shown only when the organisation has agents: the sub-agents it onboarded, in full, since the same people already see those agents’ transactions in the register. See Read your estate.

API access. Shown only when the organisation holds an API client: each client’s client_id, status, scopes, rate limits, IP allowlist, last use, fee account and tariff; usage over a window; and the periods actually charged, with anything outstanding. Never a secret. See API access and billing.

Team. ADMIN only: the members of this organisation, invite a colleague with a role, change a role, suspend or reinstate a membership, re-send an invitation. An ADMIN cannot remove the organisation’s last administrator, and cannot touch a person’s membership of another organisation.

Settings. The signed-in person’s own account details, two-factor enrolment, and regenerating recovery codes. Password change and the session list are not on this page yet (see the note above).

What the portal is not

It does not issue API clients, rotate secrets, register webhooks, create virtual accounts or move money. Each of those either belongs to the API or runs through the bank’s own approval process, and keeping them out of a browser session is the point.