Implementation process
Every implementation is different, but the work should be explicit: source systems, portfolio structures, data quality, policy checks, workflows, reports, API access, users, approvals and go-live criteria. OneBook is implemented as a governed operating book above IBOR, PMS, OMS, risk, research and reporting systems so teams can preserve context without migrating the entire firm to a new front-to-back suite.
Methodology
A successful implementation is not only a software install. It is a controlled change project across data, workflow, permissions and operating ownership. The methodology below is designed to adapt to each client while keeping the project concrete enough to track: what is being connected, who owns each decision, what is tested, and when the team is ready to go live.
Timeline
The exact length depends on asset-class breadth, custodians, administrators, policy rules, reporting needs, integrations and whether the project changes the operating model. A focused rollout can be measured in weeks; a larger operating-model program can run several months.
Default path for a focused workflow: one book, limited integrations, clear owners and a contained go-live.
Fuller path for more sources, broader policy/risk scope, API/SDK/MCP access and a structured parallel run.
Project profiles
The same product can support a narrow launch, a controlled migration away from manual glue or a larger operating-model change. The difference is the number of workstreams, data sources, control requirements and decision records that need to be production-ready on day one.
A new or focused team can start with portfolio state, holdings, cash, instrument master, governed access and one workflow such as reporting, risk review or Decision Packets.
A manager with existing books can migrate operating context from spreadsheets, internal tools and disconnected reports into OneBook while keeping core systems in place.
A broader program can include operating-model change, multiple custodians, outsourcing/middle-office redesign, richer policy configuration and more formal project governance.
Responsibilities
OneBook implementation works best when responsibilities are explicit. OneBook owns platform setup, integration execution, configuration support and training. The client owns operating decisions, source-system authority, validation and final sign-off. Larger programs can add a third-party PMO or consultant if the scope warrants it.
Data setup
The fastest implementations start with a clear operating map: entities, portfolios, cash accounts, instrument identity, source files, current holdings, user roles and data-quality expectations. OneBook can support manual uploads, automated feeds, APIs, warehouse extracts and managed integration patterns depending on the source.
Legal entities: funds, management companies, custodians, prime brokers, brokers, administrators and service providers.
Portfolios, books, sleeves, strategies, share classes, mandates and reporting groupings.
Cash accounts, currencies, settlement locations, margin accounts and account-to-portfolio mappings.
Instrument universe, issuer hierarchy, identifiers, vendor mappings, corporate actions and restricted lists.
Existing holdings, lots, cash balances, transactions, valuation snapshots and historical extracts.
Users, roles, teams, tenants, API scopes, SDK access, MCP tools and agent permissions.
Data quality controls, exception states, stale-file checks, reconciliation tolerances and lineage requirements.
Workflow configuration
The goal is the right level of flexibility: standardized objects and defaults where they reduce implementation risk, configurable workflows where each investment office is genuinely different, and custom code only where it creates durable value rather than permanent maintenance debt.
Cash-account mapping, portfolio book mapping and source-to-OneBook transformation rules.
Trading and order-workflow integrations, including OMS/PMS handoff, broker files and certification where required.
Custodian and administrator files for positions, cash, transactions, NAV, fees and reconciliations.
Scheduled price, FX, benchmark, factor, risk and valuation snapshots.
Position, cash, NAV, exposure, P&L and report reconciliation workflows.
Fee, commission, withholding tax, market-rule and instrument-specific calculation rules where in scope.
Mandate, concentration, liquidity, exposure, restricted-list and pre/post-trade policy checks.
Approval workflows, four-eye review, rule severity, breach handling, overrides and attestation routines.
Report packs, Decision Packets, export controls, API/SDK/MCP access patterns and audit requirements.
Flexibility
Investment teams should not have to choose between a simple tool they outgrow and a flexible platform that is too complex to implement or maintain. OneBook is designed around reusable portfolio, decision, access, risk and reporting objects so the firm can adapt workflows without rebuilding the system for every exception.
Portfolio state, instrument master, uploads, permissions, reporting snapshots, audit and Decision Packet patterns.
Books, sleeves, approval routes, policy checks, reconciliation tolerances, data mappings, reports and access scopes.
UI, API, SDK and MCP access for internal tools, notebooks, reports, agents and operating workflows.
Implementation cost
Implementation effort should be visible before the project starts. The main drivers are integrations, data history, asset-class breadth, policy depth, reporting scope, operating-model change and UAT rigor. The cost reducers are reusable OneBook objects, configurable workflows, best-practice defaults and structured data-loading tools.
FAQ
Most focused implementations are measured in weeks. Larger programs can run from three to twelve months when they include broad asset-class coverage, many custodians, a new operating model, formal parallel run, complex policy rules or wider system-landscape change.
No. OneBook is normally implemented above the systems already running the firm. It preserves portfolio state, decision context, risk checks, approvals, reports, API access and replay records while source systems continue to perform their existing roles.
Not for every rollout. For larger programs involving operating-model change, outsourcing, a large system landscape or formal program governance, an independent consultant or PMO can help coordinate workstreams. OneBook can work with that model if the client wants it.
Useful inputs include sample source files, portfolio structures, cash accounts, instrument files, target reports, approval policies, current workflows, data-quality checks, user groups and examples of decisions or reports that must be replayable.
They are configured as governed access paths, not side doors. Internal tools, notebooks and agents receive scoped access to IBOR, PMS, risk, reporting and Decision Packet context with the same permissions, audit and lineage expectations as the UI.
Start with one workflow
A useful implementation discussion starts with one real example: a portfolio number nobody fully trusts, a rebalance that needs approval evidence, a report pack assembled manually, an API/MCP access request, or a decision that must be replayed months later.
Request Demo