A portfolio management system (PMS) is the operational backbone for investment firms: it turns positions, transactions, and corporate actions into reliable performance, reporting, and audit-ready evidence. In practice, a PMS is less about “nice dashboards” and more about whether your team can run daily operations consistently – across custodians, asset classes, and regulatory expectations.
TL;DR: what to evaluate
- Can it produce accurate positions and performance you can reproduce on demand?
- Does it handle multi-custodian reality (interfaces, reconciliation, exceptions)?
- Are controls and audit trails built-in (not spreadsheet-based)?
- Can you scale operations with roles, workflows, and automation?
- Is pricing transparent enough to compare apples to apples?
- Does it reduce manual work and operational risk (rework, Legal/Compliance)?
Who this checklist is for
This guide is designed for teams who need institutional-grade operations and evidence – without turning every process into a manual project.
- Independent asset managers (IAMs)
- Family offices
- Private banks and wealth managers
- Institutional investors and fund administrators
If you manage multiple portfolios, multiple custodians, or multiple reporting obligations, the “selection” question is usually a “risk and operating model” question.
Core PMS capabilities (must-haves)
A PMS should give you a single, consistent operational truth – then make it easy to prove that truth.
Must-have capabilities to confirm early
- Positions and transactions: accurate holdings, cash, accruals, FX, and transaction history
- Corporate actions: processing, validation, and exception handling (not silent failures)
- Performance: time-weighted and money-weighted options (where relevant), with clear methodology
- Reporting: adaptable templates (to your client/regulatory needs), parameter control, and reproducibility
- Permissions: role-based access that matches your segregation-of-duties needs
- Support options: clear tiers and SLAs (Standard, Premium, 24/7 where needed)
- Data recovery: built-in backup/versioning so incorrect changes can be rolled back and audited
Red flag: If the vendor cannot reproduce the same report twice with the same parameters, you are not buying a system – you are buying ongoing manual reconciliation.
Data & integrations (where projects succeed or fail)
Most PMS projects fail at the data layer, not the UI.
What to validate
- Multi-custodian connectivity: coverage, maintenance model, and how breaks are handled
- Reconciliation workflow: daily controls, exception queues, ownership, and auditability
- Market data: provider support, mapping, corporate actions feeds, and fallback logic
- Accounting / general ledger: if needed, how postings, valuations, and period closes work
- CRM and client data: whether client/mandate data stays consistent across tools
- Document systems: ability to link evidence (statements, confirmations, agreements) to portfolios and decisions
Practical test: Ask the vendor to show one “bad day” scenario – missing prices, broken interface file, or corporate action mismatch – and how the system surfaces, assigns, and resolves it.
Compliance & audit trail requirements (FIDLEG / MiFID II)
Compliance is not a module you “turn on.” It’s the ability to demonstrate consistent controls and decision evidence.
What a PMS should support (in a FIDLEG/MiFID II-aware environment)
- Structured client and mandate data (objectives, constraints, risk profile where applicable)
- Restrictions that are enforceable rules (not only PDFs)
- Pre-trade and post-trade checks, including overrides with rationale
- Best execution evidence: timestamps, routing/venue fields, exception documentation
- Audit trail: who changed what, when, and why – exportable for a defined period
- Retention and recordkeeping: versioning for key records and documents
Outcome to aim for: You can produce an evidence pack in hours, not weeks.
Implementation & operating model
A PMS selection is an operating model decision: who owns data, who resolves exceptions, and how changes are governed.
Key questions
- Implementation timeline and dependencies (data, interfaces, reporting)
- Migration approach (phased vs big bang)
- Training plan by role (front office, operations, compliance)
- Support model and SLAs (including escalation)
- Change management: releases, testing, and communication
- Costs: implementation fees, support, and recurring costs
- Modular rollout possible: start with a partial implementation and add modules later (automation, data feeds, additional capabilities)
Tip: Ask for a sample project plan and a clear list of what the vendor needs from you in week 1, week 4, and week 8.
Security & governance
Security is not only about hosting. It’s about access, logs, and operational resilience.
Minimum expectations
- Role-based access control (RBAC)
- Segregation of duties support
- Immutable logs / audit exports
- Backup and recovery approach
- Environment separation (prod/test) and controlled releases
Pricing model: how to compare apples to apples
PMS pricing can look simple until you add the real drivers: users, interfaces, asset classes, reporting, and support.
Common models
- Base fee + per-user + per-interface (often easiest to forecast)
- AUM-based pricing (can look attractive early, grows with success)
- Usage-based add-ons (document processing, data extraction, automation)
Hidden cost checklist
- Interface onboarding and ongoing maintenance
- Custom reports and “one-off” data work
- Additional environments (test, UAT)
- Premium support tiers
- Data provider pass-through costs
PMS requirements checklist (table)
Use this table to compare vendors using the same lens. Keep answers testable: demos, exports, logs, and references.
| Requirement | Why it matters | Questions to ask the vendor | Evidence to request |
| Accurate positions and cash (incl. accruals/FX) | Errors here cascade into reporting, risk, and client trust | How do you calculate holdings and cash? How are breaks surfaced? | Position report + reconciliation example |
| Full transaction history with traceability | You need to reconstruct decisions and outcomes | Can we trace a position back to trades and corporate actions? | Transaction export + audit trail sample |
| Corporate actions processing + exception handling | Silent CA errors create hidden P&L and compliance risk | How are corporate actions validated? Who gets notified? | CA log + exception queue screenshot/export |
| Performance methodology clarity + reproducibility | Performance disputes are trust killers | Which methodologies are supported? Can we reproduce results? | Performance report reproduced twice |
| Reporting templates + parameter control | Consistency and auditability depend on controlled parameters | Can we lock/report parameters? How are templates governed? | Template list + sample outputs |
| Multi-custodian interfaces + maintenance model | Interfaces are a long-term operational dependency | Who maintains interfaces? How often do they break? | Interface coverage list + reference client |
| Reconciliation workflow (ownership + logs) | Reconciliation is where “truth” is proven daily | How are breaks assigned, tracked, and closed? | Reconciliation log + closed case |
| Role-based access control and segregation of duties | Prevents errors and supports governance | Can we model roles by function? Are approvals supported? | Role matrix export + permissions demo |
| Restrictions as enforceable rules | PDFs don’t prevent breaches | Can restrictions be codified and versioned? | Restriction set export + effective dates |
| Pre-trade checks + override approvals | Prevents breaches before they happen | Can we block trades? How are overrides approved? | Alert log + override record |
| Post-trade monitoring + breach register | You need a consistent breach process | How are breaches recorded and remediated? | Breach register + closed case |
| Best execution evidence (timestamps/venue) | Evidence needs to be reconstructable | What order fields are captured? Can we export them? | Order blotter export |
| Audit trail export (who/what/when/why) | Audits require proof, not narratives | What logs exist and how do we export a date range? | Audit export sample |
| Document linkage (agreements, statements, confirmations) | Evidence should be findable and contextual | Can we link docs to client/portfolio/trade? | Sample client file pack |
| Support SLA + escalation path | Downtime and delays are operational risk | What are response times and escalation steps? | SLA document + reference call |
Common requirements INSA customers prioritize (factual)
Across selection projects, teams typically prioritize:
- Multi-custodian consolidation as a daily operating reality
- A PMS that supports repeatable reporting (same inputs, same outputs)
- Audit-ready evidence: logs, exports, and traceability without manual reconstruction
- A modular approach that scales from current needs to future complexity
- Long-term vendor support that matches the operational criticality of the platform
If you want to see how INSA approaches these requirements, contact us for a demonstration.
FAQ
What’s the difference between a PMS and an OMS?
A PMS is the system of record for portfolios: positions, transactions, valuations, performance, and reporting. An OMS focuses on order creation, routing, and execution workflows. Some platforms combine both, but you should confirm which system is the “source of truth” for holdings and performance.
How long does PMS implementation typically take?
It depends on interfaces, data quality, and reporting scope. A basic setup can be relatively fast, but multi-custodian connectivity, historical data migration, and report validation often drive timelines. Ask vendors for a phased plan with clear milestones.
What data should we prepare before migration?
At minimum: client/mandate data, portfolio structures, instrument master data, historical transactions, corporate actions history (if needed), pricing sources, and reporting requirements. Also prepare a reconciliation approach: how you will validate positions and performance.
How do we evaluate multi-custodian connectivity?
Don’t only ask “Do you support custodian X?” Ask how interfaces are maintained, how breaks are detected, and what the workflow is when a file changes. Request a reference client with a similar custodian mix.
What reports should a PMS produce out of the box?
Common essentials include holdings, transactions, performance, asset allocation, cash, fees, and client-ready statements. The key is not the list—it’s whether reports are reproducible and parameter-controlled.
What compliance features are essential for FIDLEG/MiFID II?
You want structured client/mandate data, enforceable restrictions, pre- and post-trade checks, best execution evidence, and exportable audit trails. The goal is consistent controls and evidence without manual reconstruction.
How do we compare PMS pricing models fairly?
Normalize pricing by your real drivers: number of users, number of custodian interfaces, reporting complexity, asset classes, and support tier. Ask for a 3-year total cost estimate including implementation, interfaces, and likely add-ons.
What are the most common reasons PMS projects fail?
Unclear ownership of data, underestimated interface and reconciliation work, reporting scope creep, and lack of user adoption. A successful project aligns the PMS with an operating model: roles, workflows, and governance.
Should we choose cloud or on-premise for a PMS?
It depends on your security requirements, internal IT capabilities, and governance preferences. Cloud can simplify updates and scaling; on-premise can offer tighter internal control. In both cases, insist on clear access controls, logs, backups, and a tested recovery plan.
What should we demand in a support SLA?
Clear response and resolution targets, escalation paths, coverage hours, and definitions of severity levels. Also ask how the vendor handles interface breaks and whether premium tiers meaningfully change outcomes.
Download: vendor evaluation scorecard (PDF)
If you want a simple, internal scoring tool, use a 0–2 scale:
- 0: Not supported / cannot be demonstrated
- 1: Partial, manual workaround, or not traceable
- 2: Built-in, consistent, traceable, exportable
Tip: We added a column for “Evidence location” (report name, screen, export) so you can build an audit-ready selection file
Just enter the form and we send the PDF directly into your mailbox.

