Access control and operational authority
Make operational authority explicit
In a financial system, “who was allowed to do this?” needs a clear answer. HOLD OS builds authority from three explicit parts and never infers one from another.
- Role The user’s position in the institution
- Account Where they are working
- Asset The asset the operation concerns
Permitted operation Only when all three agree
Role and the current account
A user’s authority is not limited to their role; it also depends on the account they are working in. Someone with authority in one account does not automatically have it in another.
For sensitive changes, such as changing the institution’s assets, the user’s role is checked again at that moment rather than relying on the state at sign-in.
Asset-scoped operations
Operational authority can be limited to a specific asset. Selecting an asset in the interface only sets the display context and the permitted operations for that asset; an old form or an earlier selection never authorizes an operation on another asset.
Access to the brand studio, or being an ordinary administrator, does not create authority over the institution’s assets. Choosing active and default assets and registering Custom assets belong to the general administrator.
Sign-in methods
Signing in to HOLD OS is straightforward and configurable. Each additional factor is enabled by the person or body responsible for it.
-
Username and password
The default sign-in method for every account.
-
SMS
A policy the institution’s general administrator decides on.
-
Personal Authenticator
The account holder’s own security choice; once enabled, it is also used to confirm sensitive changes.
Approval boundaries
Some operations require identity to be confirmed again, or a specific authority.
| What to evaluate | How HOLD OS approaches it |
|---|---|
| Changing the institution’s active assets | General administrator only, with the current password and, when enabled, Authenticator. |
| Approving a trade | Only a person with authority in that account, for that asset. |
| Creating an account | The institution’s private process; no financial authority is granted automatically. |
A simple responsibility map
To evaluate HOLD OS, place your institution’s current responsibilities beside this structure: who sets assets and rules, who creates accounts, and who approves trades.
In a walkthrough we go through this map using your organization’s actual roles.
- General administrator
- Active assets, default asset and sign-in policy
- Operations team
- Accounts, review and approval within their authority
- Customer
- Their own account and personal Authenticator
Assess your institution’s authority structure
In a walkthrough we examine roles, accounts and approval boundaries using your scenario.