CISI Technology in Investment Management common mistakes
CISI Technology in Investment Management · Understand the traps and how to avoid them.
Treating the IBOR and the accounting book of record as interchangeable, and answering questions about 'the investment book of record' as if it were simply the general ledger or the custodian's record.
Candidates learn 'book of record' as a loose synonym for 'system that holds positions' and never separate the three books: the IBOR (investment/order-driven, intraday, front-office view), the ABOR (accounting, valuation, NAV), and the PBOR (prime broker or custodian record). Exam items test precisely the reconciliation and ownership boundaries between them, so a candidate who collapses them picks the plausible-but-wrong option.
What to do instead
Build a one-page comparison table with columns: primary user, timing/frequency of update, what it is authoritative for, and typical reconciliation direction. Memorise that the IBOR is the front-office authoritative position view built from orders, executions and corporate actions, that the ABOR is the accounting record used for NAV and financial reporting, and that the PBOR sits at the broker/custodian. Then practise classifying scenarios ('the portfolio manager needs an intraday exposure' vs 'the fund needs a month-end NAV') to the correct book.
Assuming T+1 settlement means the trade is affirmed, confirmed and settled on trade date, and picking answers that compress the whole post-trade lifecycle into one day.
The shortened settlement cycle is widely reported as 'T+1', and candidates conflate the settlement date with the confirmation and affirmation deadlines that precede it. They forget that allocation, confirmation, affirmation and matching must still happen, just within a tighter window (typically affirmation by end of trade date under T+1 in the US), and that FX funding and securities lending recalls must be pulled earlier.
What to do instead
Draw the lifecycle as a timeline: execution, allocation, confirmation, affirmation, matching/central matching, settlement instruction, pre-settlement matching, settlement, fails management. Label which steps moved earlier when the cycle shortened and which did not move at all. Learn the difference between confirmation (counterparty agrees the economics) and affirmation (the underlying client/allocated account agrees), and be able to explain why T+1 increases pressure on affirmation rates and same-day FX.
Answering data-quality questions by naming a tool ('a data warehouse', 'an ETL job', 'a dashboard') rather than identifying the control, the dimension of data quality, or the accountable owner.
Candidates revise technology as a product catalogue and reach for a system name whenever they see 'data quality'. Exam items usually ask which control detects or prevents a specific defect, or which data-quality dimension (completeness, accuracy, timeliness, consistency, validity, uniqueness) is breached by a described symptom.
What to do instead
Learn the data-quality dimensions with a concrete symptom for each, and pair each with a typical control: completeness with mandatory-field and record-count reconciliation; accuracy with independent source-to-target reconciliation; timeliness with latency SLAs and stale-price checks; consistency with cross-system matching; validity with reference-data and format rules; uniqueness with duplicate detection on instrument and counterparty identifiers. Practise mapping a scenario to dimension plus control plus owner (data steward vs data owner vs technology).
Treating FIX as a data standard or a settlement messaging standard, and confusing it with ISO 15022/ISO 20022 in questions about messaging.
Both are 'message standards' in casual reading, so candidates lump them together. In reality FIX is a session-based protocol for pre-trade and trade execution messaging between counterparties, while ISO 15022 and ISO 20022 are the SWIFT-family standards used for post-trade, corporate actions, payments and securities messaging, with ISO 20022 based on XML.
What to do instead
Memorise a simple split: FIX = execution and order messaging, tag-based, session layer, front-office. ISO 15022 = legacy SWIFT MT-style syntax for settlement and corporate actions. ISO 20022 = XML-based, richer data model, migrating payments and securities messaging onto one standard. Then answer messaging questions by first deciding which stage of the lifecycle the message belongs to, and only then choosing the standard.
Confusing the roles of an order management system, an execution management system and a portfolio management system, and attributing order routing or pre-trade compliance to the wrong layer.
In practice these systems overlap and vendors bundle them, so candidates who have seen a combined OMS/EMS assume the functions are interchangeable. Exam items often hinge on which component holds the order state, which routes to venues and manages algorithms, and which holds positions, cash and pre-trade compliance checks.
What to do instead
Learn the canonical division: the OMS owns the order lifecycle, allocations and often pre-trade compliance and the order/position feed to the IBOR; the EMS owns venue connectivity, algorithmic execution, smart order routing and execution analytics; the PMS owns portfolio construction, modelling and performance. Then practise 'which system does X' questions, noting where vendors blur the boundary and why the exam answer follows the canonical model rather than a specific vendor's packaging.
Answering AI and machine-learning questions with generic enthusiasm ('AI improves efficiency and reduces cost') instead of naming the specific model risk, data dependency or governance control being tested.
Candidates without a quantitative background default to benefit statements because they cannot distinguish supervised learning from unsupervised learning, or explainability from accuracy. Exam items typically test concepts such as overfitting, training-data bias, model drift, explainability versus performance trade-offs, and human oversight obligations.
What to do instead
Learn a small vocabulary precisely: supervised vs unsupervised vs reinforcement learning; training, validation and test data; overfitting and regularisation; feature importance and explainability; model drift and monitoring; back-testing bias. For each, write one sentence on the investment-management use case (for example sentiment analysis on research, or trade-cost prediction) and one on the control that mitigates the risk. Answer AI governance questions by naming the control and the accountable function, not the benefit.
Treating cyber security and operational resilience as synonyms, and answering resilience questions with security controls such as firewalls and multi-factor authentication.
Both sit under 'technology risk', so candidates answer every question in the area with the controls they know best. Resilience questions are about the ability to prevent, adapt to, respond to, recover from and learn from disruption, tested through impact tolerances, important business services and severe-but-plausible scenarios; security questions are about confidentiality, integrity and availability controls against malicious actors.
What to do instead
Separate the two frameworks explicitly. For resilience, learn the vocabulary of important business services, impact tolerances, severe but plausible scenarios, mapping of dependencies (people, process, technology, third parties), and testing through scenario exercises. For cyber, learn the control families: identity and access management, patching and vulnerability management, network segmentation, encryption, logging and monitoring, incident response, and third-party/ supply-chain risk. When a question mentions 'impact tolerance' or 'important business service', answer from the resilience framework; when it mentions 'phishing' or 'ransomware', answer from the security control set.
Giving one-directional answers on outsourcing and cloud, either 'outsourcing always transfers the risk' or 'outsourcing is prohibited for critical functions', instead of applying the regulated firm's retained accountability and the notification/approval requirements.
Candidates remember headline enforcement actions and over-generalise. The consistent regulatory principle is that a firm can outsource the activity but not the accountability: it retains responsibility for the service, must perform due diligence and ongoing monitoring, must have exit plans, and must notify or obtain approval from the regulator for material arrangements.
What to do instead
Learn the outsourcing lifecycle as a checklist: risk assessment and materiality classification, due diligence, contract terms (audit rights, data location, sub-outsourcing, service levels, termination and exit assistance), regulatory notification or approval, ongoing monitoring and SLAs, concentration risk, and exit planning. Practise distinguishing 'material' from 'non-material' arrangements and identifying which obligations survive outsourcing. Never select an option that says accountability transfers.
Confusing regulatory reporting technology with compliance monitoring technology, and answering MiFID-style transaction reporting questions with surveillance or best-execution controls.
Both are 'regtech', so candidates pick whichever compliance system they recall. Transaction reporting (for example instrument, price, quantity, buyer/seller identification, reference data accuracy, T+1 submission) is a data-extraction and validation problem; trade surveillance and best execution are monitoring and review problems over conduct.
What to do instead
Map each regulatory obligation to its technology solution: transaction reporting to extraction, enrichment, validation and submission with reference-data quality controls; best execution to execution-quality analytics and venue analysis; market abuse surveillance to alert generation and review workflows; communications surveillance to capture, retention and lexicon monitoring; client money and asset reconciliation to daily reconciliation engines. Learn the typical failure points for transaction reporting specifically: missing or stale reference data, incorrect counterparty or trader identification, and late or rejected submissions.
Reading change, vendor and emerging-technology questions as project-management trivia and choosing answers based on 'best practice' instinct rather than the specific delivery model, testing stage or contractual control being described.
Candidates underestimate this domain because it feels like soft skills, so they do not learn the distinct vocabulary: waterfall versus agile versus hybrid, user acceptance testing versus parallel running versus pilot, request for information versus request for proposal, proof of concept versus minimum viable product, and the vendor selection and contract governance stages. The distractors are all plausible-sounding good practice.
What to do instead
Build a glossary that pairs each term with a distinguishing feature and a typical exam trap. For example: an RFI gathers capability information before requirements are fixed, an RFP asks for priced proposals against defined requirements; a proof of concept validates feasibility with no production commitment, a pilot runs in production with limited scope; parallel running mitigates migration risk by operating old and new systems together. For vendor management, learn the difference between service-level agreements, key performance indicators and key risk indicators, and where each appears in contract governance.