Access and record integrity
Clear controls over access and records
Confidence in a financial system comes from clear rules. This page describes precisely what HOLD OS does about sign-in, authority and records, so your team can measure it against its own requirements.
What the product defines
The mechanisms below are part of the HOLD OS product contract. This page does not claim a security certification, an independent audit or regulatory approval.
- Sign-in
- Username and password, with SMS as the institution’s choice and Authenticator as the account holder’s choice.
- Authority
- Each operation’s authority set by role, account and asset.
- Sensitive changes
- Changes to the institution’s assets confirmed with the current password and, when enabled, a second factor.
- Records
- The original identity and unit of every asset record is preserved.
Sign-in methods
Each sign-in factor is enabled by the person or body responsible for it. Not every factor needs to be active for every account.
-
Username and password
The default sign-in method.
-
SMS
A policy decided by the institution’s general administrator.
-
Personal Authenticator
The account holder’s own security choice.
Operational authority
There is no implied authority in HOLD OS. Creating an account moves no money and grants no financial authority. Access to the brand studio, or being an ordinary administrator, does not create authority over the institution’s assets.
Selecting an asset in the interface only sets the display context and the permitted operations for that asset; an old form never authorizes an operation on another asset. If the asset catalog is damaged or incomplete, new operations stop, and the system never silently falls back to another default asset.
- Role The user’s position
- Account Where the operation happens
- Asset What the operation concerns
Permitted operation Only when all three agree
Historical consistency
Financial records must stay what they were when they were recorded. HOLD OS preserves this principle in several places.
| What to evaluate | How HOLD OS approaches it |
|---|---|
| Display name changes | Do not change an asset’s financial identity or the identifiers of historical records. |
| Active or default asset changes | Earlier records are never converted or relabelled as another asset. |
| Asset deactivated | New entries are restricted; existing balances and obligations continue. |
| Uncertain response to an operation | The recorded result of that same request is returned; the operation is not run again. |
Responsibilities and pre-deployment review
The security of a financial system does not depend on software alone. Hosting infrastructure, password policy, role design, internal procedures and backups all play a decisive part in each institution.
Before deployment, these responsibilities should be reviewed and assigned together with the institution’s team. Bring your security questions to a walkthrough so they can be answered precisely for your environment.
Bring your security questions
Include your questions about access and records in your email so they are covered in the walkthrough.