Compliance-ready software for asset managers: what to build in from day one

Compliance feels like the boring part of a fund platform, the part you'd add later once the features work. That instinct is expensive. The pieces that satisfy an auditor aren't features you stick on top; they're properties of how the system stores data and controls access. Try to add them after the fact and you're not adding a feature, you're rebuilding the foundation.

The funds that get this right treat compliance as structural from the first commit. Four pieces carry the weight.

1. The audit trail

An audit trail is an immutable record of every action that touched money or data: who calculated NAV, who approved a payout batch, who changed an investor's terms, and exactly when. Immutable means no one can edit or delete an entry after the fact, including an administrator.

This is the single thing a spreadsheet can never provide. A spreadsheet shows the current state, not the history of who changed what. When an auditor asks how a figure was reached, "the spreadsheet says so" isn't an answer. A logged trail that shows the calculation, the inputs, and the person who ran it, is.

Built in, the audit trail is a write that happens alongside every action. Retrofitted, you have to find every place the system changes data and add logging to each one, while hoping you didn't miss any. The first costs days. The second costs weeks and leaves gaps.

2. Role-based access control

Not everyone should see everything. An investor sees their own position and nobody else's. An accountant sees the books but can't change investor terms. An auditor gets read-only access to everything. A fund manager sees the whole fund. Role-based access control encodes those boundaries so the system enforces them, instead of relying on people to be careful.

The reason this has to be structural is that access control isn't a screen, it's a rule applied to every piece of data the system serves. Every query has to ask "who's asking and what are they allowed to see?" Build that in from the start and it's automatic. Add it later and you audit every data path in the system to insert the check, which is exactly the kind of change that introduces the leak it was meant to prevent.

ZestAMC runs five role-based portals: investor, manager, accountant, and more, each seeing only what its role permits. That separation was built into the data layer, not painted on at the end.

3. KYC and AML at onboarding

Know Your Customer and Anti-Money Laundering checks verify that an investor is who they claim and that their capital is clean. Any fund taking outside money faces these obligations, and regulators expect a process you can prove, not a folder of emailed passport scans.

Built into onboarding, KYC runs through a provider like Sumsub or Onfido the moment an investor signs up. They upload ID, the provider verifies it, and a pass or fail lands in your review queue with a record attached. The manual version, chasing documents over email and filing them in a drive, is slower, less reliable, and leaves you assembling evidence by hand when an auditor asks.

ZestAMC verifies investors through Sumsub at onboarding. The check is part of signing up, not a separate task someone has to remember to do.

4. Data security

Fund platforms hold exactly what attackers want: investor identities, financial positions, and bank details. Security here means encryption in transit and at rest, access logging, secure authentication with two-factor, and a tested permission model. These aren't optional for financial data, and a single missed input check can expose the whole dataset.

The connection to the rest of this list is direct: role-based access and audit logging are most of what data security means in practice. Build those well and you've done the heavy lifting. Skip them and no amount of later patching makes the platform trustworthy.

The cost of building in vs bolting on

The 3-4x figure isn't an estimate plucked from the air. It reflects what happens when a cross-cutting concern, something that touches every part of the system, gets added after the parts already exist. You don't write it once; you edit everywhere.

What this means for SaaS vs custom

SaaS platforms come with compliance features pre-built, which is a real advantage if your fund fits their model. The catch is that their compliance fits their assumptions about how a fund operates, not yours. If your structure or your regulator needs something the platform doesn't do, you're stuck with their version.

A custom platform lets you build the exact compliance your fund and jurisdiction require, owned by you. The trade is that you have to build it right, which is why making these four pieces structural from day one matters so much. Done well, a custom build gives you compliance that fits and an audit trail you control. For the wider build-versus-rent decision, see custom vs SaaS for fund management.

The one rule

Decide compliance before you decide features. The audit trail, the access model, and the security posture are the foundation everything else sits on. Pick them first, build them in, and the rest of the platform inherits them for free. Leave them for later and you pay 3-4x to dig back down to a foundation you should have poured at the start.