Team, Roles, API Keys, and Risk Limits
Multi-user organisations with role-based access control, programmatic access via API keys, configurable spending caps at the organisation and key level, balance alerts, and a Maker-Approver-Signer multi-signature workflow for treasury-grade transfers.
Who this is for
| Persona | Typical inbound |
|---|---|
| Any enterprise customer | ”Can we have separate accounts for finance and operations, with different permissions?” |
| Merchant with backend automation | ”We need API keys with strict spending limits — what is the maximum we can cap per day?” |
| CFO or risk officer | ”Can we set up an alert when our hot-wallet stablecoin balance drops below a threshold?” |
| Treasury operations team | ”Can we require two-person approval before any transfer above a certain size?” |
Not a fit if you need row-level authorisation (we provide resource-and-action role-based access control, not row-level), require fully custom roles defined per merchant (roles are platform-defined and merchants assign from the supplied set), or need a single login spanning many independently-licensed organisations under one identity (multi-organisation context switching is supported but a single-sign-on bridge for organisation IT systems is on the roadmap).
What you can ship today
Five capabilities, each independently usable:
| Capability | What it is |
|---|---|
| Multi-user team management | Invite, edit, and remove members. Each member is assigned one or more roles. |
| Role-based access control | Permissions resolved server-side per resource and action. The Studio console gates UI based on the resolved permission set. |
| API keys | Per-organisation programmatic credentials. The secret is shown only once at creation; capture it then or rotate. |
| Risk limits | Organisation-wide daily outflow caps, per-transaction maximums, and per-API-key versions of the same. Daily counters reset at midnight UTC. |
| Balance alerts | Organisation-wide stablecoin balance threshold. The state flips between healthy and low based on total USD value across stablecoin holdings. |
For treasury-grade transfers, an additional multi-signature operator workflow is available — see below.
Roles in the standard set
The platform ships a standard role taxonomy covering common operational personas. Roles are server-defined; you assign members to one or more of them.
| Role family | Function |
|---|---|
| Maker | Initiates transfers and other workflow actions |
| Approver | Approves actions above a configured threshold |
| Signer | Executes the approved on-chain transaction, subject to a daily transfer limit |
| Reviewer (compliance) | Opens and decides on KYC and KYB cases — see KYB and KYC Workflow |
| Admin | Manages members, roles, API keys, organisation settings |
| Read-only | Views dashboards, reports, and case lists without write actions |
The Maker, Approver, and Signer triad is the foundation of the multi-signature treasury workflow. An onboarding banner inside Studio prompts your organisation to designate at least one member to each of the three roles before treasury features are usable.
How it works
1. Your organisation is provisioned with an admin member at sign-up.
2. The admin invites additional members by email, assigning roles
from the standard role set. Each invitee accepts via an email
link and lands in your organisation's Studio context.
3. For programmatic access, the admin generates an API key from
Studio. The secret is shown ONCE on creation — copy and store it
in your secret manager immediately.
4. The admin configures risk limits at two layers:
- Organisation-wide: total daily outflow cap, per-transaction max
- Per-API-key: same fields, scoped to one key
Setting a limit clears it; leaving the field unchanged preserves
the existing value.
5. For treasury workflow, the admin assigns Maker, Approver, and
Signer roles, and configures per-operator daily-transfer
thresholds and approval thresholds.
6. Optionally, the admin enables a balance alert — total stablecoin
USD value across the organisation, with a configurable threshold.
The alert state is exposed for monitoring; auto-pause behaviour
is on the roadmap.
7. Every transfer hits all relevant limits in order:
organisation-level → per-API-key (if applicable) →
per-operator (treasury workflow). A transfer above any cap is
rejected; a transfer above an approval threshold is held for
approver action before the signer can execute it.Risk limits in three layers
| Layer | Applies to | Configurable by |
|---|---|---|
| Organisation cap | All outflow from the organisation | Admin |
| Per-API-key cap | A single API key’s outflow | Admin |
| Per-operator cap (treasury workflow) | A single Signer’s daily transfer total, plus the Approver threshold above which approval is required | Admin |
Daily counters reset at midnight UTC. Limits are enforced server-side; the Studio UI surfaces current usage against caps for every layer.
Custody model
The team, role, and risk-limit model applies to every custody surface — custodial Asset Pro treasury, embedded self-custody wallets, external-wallet tracking. The same role gates the same action regardless of where the keys live. See Custody Options for the underlying custody choices.
Compliance posture
Member invitations, role changes, API-key creation, and risk-limit edits are administrative actions logged in the platform’s operational audit trail, retained per ISO 27001 records-management standards. KYC-case mutations have a separate, per-case audit log surfaced inside the Studio compliance dashboard. See Compliance and Certifications for the full posture.
Typical integration timeline
| Path | Bucket |
|---|---|
| Stand up an organisation with two or three members and the standard role set | Under one month — typically a single day once your organisation is provisioned |
| Add API keys with risk limits for backend automation | Under one month — typically a few days for a backend team comfortable with secret management |
| Configure the full Maker-Approver-Signer treasury workflow with per-operator caps | One to two months — depends on how many operators and how strict the policy |
Current scope
- Multi-user team management, role-based access control, API keys, and risk limits are in production.
- The Maker-Approver-Signer multi-signature treasury workflow is in production, used by external integrators.
- Balance alerts are in production for monitoring; auto-pause-on-low-balance is a roadmap item.
- Email-based invitation is the standard onboarding path. SAML and SCIM integration for enterprise IT is on the roadmap.
- A webhook for permission changes (server-side acknowledgement of role updates) is on the roadmap.
Talk to us
If you need a multi-user organisation with strict spending controls and treasury-grade approval workflows, reach our partnerships team via the address on www.kryptogo.tw .
Where to go next
- Sign in with KryptoGO — for letting end users log in to your application with their KryptoGO account.
- KYB and KYC Workflow — for the compliance reviewer roles and case audit trail.
- Architecture Overview — for how identity, role-based access, and risk limits flow through the platform.
- Compliance and Certifications — for access reviews, MFA, and the supporting security posture.