Evaluating and planning HOLD OS
From your workflow to a considered decision
Before any decision, it should be clear how well HOLD OS fits your institution’s structure and process. The evaluation path is designed to answer exactly that.
The evaluation path
Evaluation starts from your needs, not from a list of features.
-
Understand the context
In your email, introduce your organization, role and main use case.
-
Walkthrough
We go through the product with your institution’s real scenarios: assets, accounts, trades and contracts.
-
Scope and proposal
We discuss the scope you need, and a matching institutional proposal follows.
-
Deployment planning
Responsibilities and prerequisites for deployment in your environment are reviewed.
Understanding your institution’s context
The clearer the context, the more precise the walkthrough. In your email, describe your main use case and your current process: which assets you work with, how your customers are organized and who approves trades.
You do not need to provide bank details, passwords or customers’ financial data at this stage.
A walkthrough built on real scenarios
A walkthrough is not the same general presentation for everyone. Based on the use case you choose, we go through the relevant parts of the product: asset definitions, account and subaccount structure, the trade workflow and, where needed, leasing contracts.
The aim is for you to compare the product’s logic with your own process and ask your questions directly.
Scope and institutional proposal
The HOLD OS platform price is USD 6,000. Commercial details specific to each institution, such as deployment scope and the services required, are set out in the institutional proposal conversation.
No delivery time or bundled service is promised before that conversation; the institutional proposal is shaped around your specific needs.
Deployment planning questions
Review these questions with your team before deployment. The answers make planning more precise.
Which assets will be active, and which will be the default?
This choice belongs to the institution’s general administrator, and the interface adapts to it.
How will roles and authority be defined?
Prepare a list of roles and the accounts and assets each role can act on.
What is the institution’s sign-in policy?
Decide whether SMS will be used as an institutional policy; Authenticator is each account holder’s choice.
Who is responsible for hosting and maintenance?
Infrastructure, backups and internal procedures should be settled before deployment.
Start the evaluation
The first step is requesting a walkthrough. Choose your institution’s main use case so the conversation focuses on it.