A financial operations platform for institutions
One clear view of institutional operations
HOLD OS is one environment for owning, holding, trading and leasing assets. This page shows how the parts of the platform connect, and why that connection matters to an operations team.
Institution, customer and subaccount
HOLD OS starts from organizational structure. The institution sits at the top and sets the active assets, rules and operational authority. Customers hold private accounts that the institution creates and manages, and subaccounts are controlled within the same frame.
There is no public signup. Accounts are created through a private process at the institution’s discretion, and creating an account neither moves money nor grants financial authority on its own.
-
Institution
Sets assets, rules and authority
-
Customer
Private account created by the institution
- Subaccount Controlled account within the customer
-
Customer
Private account created by the institution
Asset identity comes before any number
In HOLD OS every quantity belongs to a specific asset. Gold, Silver and Custom assets each have a stable identity, unit and precision of their own, and all of them use one shared financial core.
When the general administrator changes the active or default asset, earlier records do not change. A balance, contract or event recorded in Gold remains Gold; no record is converted to another asset or relabelled.
How activity flows through an account
Activity in an account follows a defined path, and every step is recorded in the same account with the same asset identity.
-
Wallets
Each asset has its own wallet and every account has one shared cash wallet; cash is recorded in whole toman.
-
Reference price
The institution records a manual reference price per asset unit; a reference price is not an approved trade quote.
-
Request and approval
A trade is requested with an explicit quantity and price and approved by someone with authority.
-
Record
The approved result is recorded against the same account and the same asset.
Trades and obligations, each in its place
Not every activity is a purchase or a sale. In asset leasing the institution manages an obligation that continues over time: the principal must come back, and rent is settled separately.
HOLD OS records these as two distinct obligations. Rent payments never reduce the principal, and the principal is returned in the same asset, unit and standard as the contract.
Leasing contract Parties, asset and approved terms
- Principal Returned in full, in the same asset and unit
- Rent A separate obligation under the approved policy
Who controls what
Authority in HOLD OS is explicit. Whether a user can see or perform an operation depends on their role, the account they are working in and the asset concerned.
Access to brand settings, or being an ordinary administrator, does not grant authority over the institution’s assets. Choosing the active assets belongs to the general administrator and is confirmed with the current password and, when enabled, Authenticator.
- Role The user’s position in the institution
- Account Where the operation takes place
- Asset The asset the operation concerns
Permitted operation Only when all three agree
Examine each capability
Every part of this picture has its own page with details and examples.
-
Multi-asset management
Definition, unit, precision and reference price for each asset.
-
Wallets and records
Asset balances versus cash, and how records are followed.
-
Trade workflows
From request to recorded result.
-
Asset leasing
Principal, rent and contract records.
-
Access control
Role, account, asset and sign-in methods.
Test this structure against your own process
In a walkthrough we go through the platform using your institution’s scenario, from customer structure to trades and contracts.