Free Sample

Chapter 2: Pre-Implementation Readiness Assessment

Before you contract a vendor, before you run a demo, before you scope the project — assess where you actually stand. This chapter covers the four readiness dimensions that determine whether your OMS implementation succeeds or drags.

What's in this chapter
  • Data readiness: security master quality, position history, and transaction data completeness
  • Integration inventory: counterparty connectivity, custodian feed status, FIX broker relationships
  • Organizational readiness: team capacity, stakeholder alignment, and vendor management structure
  • Technical infrastructure: network architecture, DR requirements, and co-location considerations
  • Readiness scoring framework with platform-specific callouts for Bloomberg AIM and Charles River
  • Red-flag checklist: the 12 indicators that your implementation is at risk before it starts
~3,200 words PDF format CRD + AIM callouts
Chapter preview

Of all the variables that determine whether an OMS implementation succeeds, the one firms control most is how they prepare before the engagement starts. Implementation failures are rarely caused by the platform or the vendor — they are caused by data that isn't ready, integrations that were underscoped, and organizations that weren't aligned. Those are readiness problems, and they are fixable if you identify them before you start.

This chapter gives you a structured framework for assessing your readiness across four dimensions: data quality, integration complexity, organizational capacity, and technical infrastructure. For each dimension, we provide diagnostic indicators, a scoring framework, and platform-specific callouts for Bloomberg AIM and Charles River. At the end is the red-flag checklist — twelve indicators that should give you pause before you kick off.

Dimension 1: Data Readiness

Data quality is the foundation on which everything else is built. An OMS cannot be configured, tested, or operated without accurate, complete, and consistent underlying data. The three data domains that matter most at implementation time are the security master, position history, and transaction history.

1.1 Security Master Quality

The security master is your most critical data dependency. Every order workflow, every compliance rule, every allocation, every custodian feed mapping runs against it. The diagnostic questions to answer:

  • What percentage of your security universe has a current, validated CUSIP? ISIN? Bloomberg security identifier?
  • How many securities carry conflicting identifiers across your source systems?
  • Do your current identifiers match the identifier scheme your target OMS expects?
  • How often do you receive and process corporate action updates?
Charles River Note

CRD primary identifier requirements

CRD's primary identifier is the CUSIP or ISIN. CRD's Financial Instrument Master (FIM) has strict validation — instruments without valid identifiers are rejected during data load.

For international securities, ISIN coverage is more critical than CUSIP. Verify completeness for all cross-listed and non-US instruments.

Bloomberg AIM Note

AIM identifier requirements

Bloomberg AIM natively uses Bloomberg security identifiers (BBGID and FIGI). If your systems are primarily CUSIP/ISIN-based, the identifier crosswalk is a non-trivial data exercise.

Securities not covered by Bloomberg Data License may require manual attribute maintenance — scope this before go-live.

1.2 Position History

Most implementations require loading position history to enable compliance and performance modules from Day 1. Firms typically need 1–3 years of position history depending on compliance rule lookback periods.

  • Is position history available in machine-readable format? From your current OMS, custodian, or accounting system?
  • Do those sources agree? Discrepancies must be resolved before migration.
  • Are corporate actions reflected correctly in the historical record?

1.3 Transaction History and Trade Records

Clean trade records are required for compliance look-back testing, performance attribution, and tax lot setup. Transaction history gaps are often invisible in legacy systems — the target platform will surface them.

  • Complete trade records (side, quantity, price, execution time, broker, account) for the period being loaded.
  • Allocations captured at lot level — block trade histories without allocation records are not portable.
  • Settlement status available or reconstructible from custodian confirms.

Continue reading: Enter your email to unlock the full chapter — including the integration inventory assessment, organizational readiness framework, and the red-flag checklist.

Download free chapter →

Get Chapter 2 free

Enter your email to download the Pre-Implementation Readiness Assessment chapter immediately.

No marketing emails. Just the chapter.

← View full Playbook and pricing