The provider console
In short
Section titled “In short”The provider console is a separate web app for the staff of the organisation that runs SpeculaPro as a hosted service (the provider). It is where they create workspaces for institutions, record what plan each one is on, see how much each uses and whether its data is flowing, post service notices, suspend a workspace, and ask a workspace for time-limited support access.
It is not part of the app your analysts use, and it does not exist on a self-hosted
installation. If your institution runs SpeculaPro on its own servers, nobody outside it has a
console like this: SpeculaPro refuses to start with the console switched on unless the installation
is a hosted one (SP_DEPLOYMENT=saas).
What the console is, in five facts
Section titled “What the console is, in five facts”| Fact | What it means |
|---|---|
| Off by default | Nothing is served until SP_PROVIDER_CONSOLE_ENABLED=true. See Setting up |
| Its own listener | The console answers on its own address (SP_PROVIDER_ADDR), never on the port customers use. It is meant to sit behind a VPN or an internal load balancer, and can be limited to named networks |
| Its own people | Provider staff are not workspace users. They have their own accounts, their own sign-in page, their own session cookie and a mandatory second factor. See Staff and roles |
| One per region | On a multi-region service each region runs its own console, over the workspaces of that region only. Nothing in it adds up across regions |
| Everything is recorded | Every sign-in, every workspace looked at and every change is written to the console’s own append-only audit log. What the provider does to a workspace is also written to that workspace’s audit log, where its administrators read it |
What staff see of a workspace
Section titled “What staff see of a workspace”The console shows what an operator needs to run the service, and stops there.
| Shown | Not shown, anywhere in the console |
|---|---|
| Name, slug, type of institution, country, currency, time zone, jurisdiction, region | Customers, accounts and counterparties |
| Status (active, suspended, closed) and any scheduled deletion | Transactions and decisions themselves |
| Plan, agreed limits and staff notes | Alerts and cases |
| How many people can sign in, and when someone last signed in | Regulatory reports |
| Transactions and real-time decisions counted per month | Rules, lists and settings |
| Health in numbers: when the latest transaction arrived, how many webhook deliveries, notifications, file loads and scheduled rules are failing | Names of the workspace’s people, API keys, secrets |
The only way a member of staff looks inside a workspace is support access: they ask, someone in the workspace approves, and a read-only session opens in the customer app for a limited time.
The sections
Section titled “The sections”| Section | What you do there | Who sees it |
|---|---|---|
| Workspaces | List, search and create workspaces; open one to see its overview, usage, plan and actions. See Workspaces and Plans and limits | Every role |
| Approvals | Approve or reject a colleague’s request to suspend, reactivate or delete a workspace. See Suspending and deleting | Owner, Operations, Support, Viewer (only Owner and Operations decide) |
| Notices | Post a banner into the customer app. See Service notices | Owner, Operations, Support, Viewer (only Owner and Operations post) |
| Support access | See requests for support access and open a session. See Support access | Owner, Operations, Support |
| Staff | Invite colleagues, change roles, reset a password or a second factor | Owner |
| Audit log | Read what staff did | Owner |
The bar at the top shows the region the console runs in (Single region when there is only one), the build, and, on anything other than production, the environment’s name. It also counts down the time left before an idle session is signed out.
Two rules that hold everywhere
Section titled “Two rules that hold everywhere”- Dual control. Suspending a workspace, reactivating it, scheduling its deletion and cancelling that deletion always take two people: one proposes, a different one approves. Nobody can approve their own request, whatever their role.
- Monitoring never stops for a commercial reason. A workspace that goes over its plan is marked and alerted on; its transactions and decisions are still taken. The one limit that is held is the number of people, and it only stops adding one more.