Investment Adviser Compliance Software Problems: The 7 That Surface During an Examination, and How to Avoid Them

Why does the every policy at once scope keep failing?

The chief compliance officer lists what hurts, and the list is long: preclearance, personal trading reconciliation, attestations, gifts and entertainment, political contributions, marketing review, outside business activities, the annual review. All of it goes into release one, because all of it is a real obligation and none of it feels optional. Four months later the firm has a half built system covering eight policies shallowly and is still running preclearance through the compliance inbox, which is the thing that actually carries enforcement risk.

What makes this specific to advisers is that the policies are not equally weighted. Personal trading is where the exposure concentrates, and it is also the area where a good system changes behaviour rather than just recording it. When preclearance answers in seconds, employees use it. When it takes a day, they quietly stop asking, and the population of unprecleared trades grows in a place nobody is looking.

Sequence accordingly. Release one is preclearance against a versioned restricted list, brokerage feed and statement ingestion with reconciliation, and the attestation cycle. Marketing review, gifts and political contributions belong in phase two. That ordering is not about engineering convenience, it is about which gap an examiner is most likely to find and which one is hardest to remediate after the fact.

What goes wrong when you migrate historical compliance records?

Three migrations look easy and are not. Brokerage history is the first. Years of statements sit as PDFs in folders named by person and year, with duplicates, missing months, and accounts for spouses that were disclosed verbally and never written down. Extracting all of it into structured transactions sounds thorough and usually produces a partial dataset that reads as authoritative, which is worse than an obviously incomplete one, because somebody will eventually run a report against it and treat the output as fact.

The restricted list is the second and it is the one that cannot be recovered. If the list has been overwritten in place since the day it was created, its history genuinely does not exist. No migration retrieves it. Pretending otherwise by loading the current list with a backdated effective date creates a record that asserts something you cannot support, which is a materially worse position than an honest gap.

Attestations are the third. Historic completions live in email threads and a spreadsheet with a tick, and there is often no record of who was chased and when, which is exactly the follow up question examiners ask about non responders.

The fix in all three cases is to draw a clean line. Migrate what you can verify, mark the boundary date explicitly in the system, and keep the pre boundary archive intact and accessible in its original form rather than transformed into structured data that implies a precision you do not have. Then start the point in time record from go live and never edit it.

Why do custodian and internal system integrations break after launch?

Brokerage feeds break in ways that are invisible from inside the system. A custodian stops sending duplicate statements for an account because a paperwork authorisation lapsed. An employee opens an account at a broker that sends nothing electronically. A feed keeps arriving but a new account on it does not match any person in your register, so it lands in a queue nobody has been assigned to watch. In every case the system looks healthy and your coverage has quietly shrunk.

The fix is coverage monitoring rather than feed monitoring. Reconcile the set of accounts you believe each access person holds against the set of accounts actually producing data, every month, and treat any account with no activity and no statement as an exception requiring a human answer. That single report catches most of what goes wrong here.

Internal integrations break differently. The link to your customer relationship management (CRM) and portfolio accounting systems is usually the reason to build in the first place, and it depends on identifiers matching between systems maintained by different teams. A security master that models equities well and options, futures, private credit or digital assets badly will silently misclassify the instruments your strategies actually trade, which means preclearance rules evaluate against the wrong attributes. Test that with your real instrument mix during selection, not after.

What happens when point in time records and trade reconciliation are not covered?

Two gaps produce findings rather than inconvenience. The first is the mutable restricted list. Examiners assess whether a compliance programme is reasonably designed and actually implemented, and implementation is demonstrated with records. If you cannot show what the list contained at a specific hour on a specific past day, you cannot evidence that a preclearance decision was correct, however correct it was. The structure required is append only and point in time, queryable by date, with every version preserved.

The second is reconciling what was precleared against what was actually executed. Manual processes almost never do this properly, because it requires joining a decision record to a transaction record across systems, and it is the check that matters most. An employee who precleared a purchase and executed a larger one, or executed on a different day, or never precleared at all, only shows up if something compares the two sets.

Both belong in the first release. The list structure is close to impossible to retrofit, because the history you did not keep cannot be reconstructed. Reconciliation is easier to add later but the exceptions it would have caught in the meantime are still exceptions when someone eventually looks. The related discipline is testing evidence: samples pulled, exceptions found, remediation completed and dated, accumulated through the year so the annual review assembles from a testing record rather than being composed in a quiet week from memory.

Should you build custom or configure what you already own?

Buy, genuinely, if you are a smaller adviser with a conventional long only strategy, mainstream custodians and fewer than about twenty employees. SmartRIA and its peers cost a fraction of a build and will carry you a long way. ComplySci and MyComplianceOffice are the sensible answer if you need broad coverage across many policies quickly and your feeds are standard. Firms that build without needing to end up maintaining software instead of running a compliance programme, which is a poor trade for an officer whose time is the scarce resource.

These products are also frequently the right foundation rather than the wrong choice. Where a firm's real problem is one thing, usually the restricted list being copied in by hand from an internal research pipeline, the cheaper answer can be to keep the vendor tool and build only the feed that keeps its list current.

Build when two or more of these are true: your restricted list is generated from internal sources such as a research pipeline or a deal list; you trade instruments the vendor's security master handles badly; you have information barriers between teams that must be enforced technically rather than by policy alone; your compliance data needs to sit alongside your customer relationship management and portfolio systems to be useful; or you have already been through an examination where the finding concerned evidence rather than conduct.

How do hidden costs get into the quote?

Policy encoding is the cost nobody quotes and everybody pays. Your code of ethics contains judgement calls that read fine in prose and cannot be evaluated by a rule engine as written. What counts as a covered security, when a holding period applies, which exemptions attach to which account types. Turning that into precise rules is work for your chief compliance officer and counsel, not for a developer, and it routinely takes more calendar time than the engineering it enables. Budget real hours from your own team.

Second, feed count. Each custodian and broker is its own connection, format and failure mode, and the ones without electronic feeds need statement extraction with a matching process behind it. Third, instrument coverage, because a firm trading options, futures, private credit or digital assets needs a security master that models what it actually trades. Fourth, affiliate structure, if you have a broker dealer or a fund complex with information barriers to enforce.

Ask two questions before contract. Exactly which custodians and brokers are in scope by name, and what happens when a statement arrives for an account nobody disclosed.

What separates a build that works from one that fails here?

Ask how the restricted list is stored. If the answer describes a table that gets updated, stop the conversation there. You need append only, point in time structure where every version is preserved and queryable by date, and a developer who does not reach for that instinctively will build you the same spreadsheet with a login screen and better colours.

Ask what they have built where the audit trail was the product rather than a feature. Financial services, clinical research and regulated manufacturing all count. What matters is whether they have designed systems in which records cannot be edited quietly and approvals are structurally verifiable.

The builds that work also respect the behavioural point. Preclearance that returns in seconds for clear cases and routes only genuine ambiguity to a human gets used. Attestations that pre populate what the firm already believes and ask the employee to confirm or correct get completed. Escalation that goes to the employee's manager on a schedule gets answered. The builds that fail are technically correct and socially ignored: a portal people log into twice a quarter, a preclearance queue with a day of latency, and a compliance officer still chasing statements by email while paying for software that was supposed to stop that.