Build vs Buy a KYC Onboarding Platform: The Requirements Matrix Is the Real Decision

Where a vendor is plainly the right answer

Retail and small business onboarding is a solved commercial problem. If a natural person arrives through an app, an identity verification provider handles document capture, liveness, sanctions screening and a risk score, and building any of that in house is expenditure with no differentiation attached. Buy it, integrate it, move on.

The enterprise argument is narrower but real. Fenergo carries the deepest client lifecycle coverage in this market and its regulatory rules library is genuine work you would otherwise fund yourself. If you are a large institution onboarding across a dozen jurisdictions, and the driver is breadth of coverage rather than the specifics of your own policy, that programme earns its place. It comes with an enterprise implementation budget and an enterprise timeline, and anyone who tells you the rules library arrives correct for your policy has not configured one.

Encompass deserves the same fair hearing. Pulling corporate registry data and assembling an ownership structure automatically removes a large amount of analyst keying, and in jurisdictions with good registry coverage it is the fastest win available to an onboarding team. ComplyAdvantage, LSEG World-Check and Dow Jones supply screening and risk data, which you should buy rather than attempt.

The honest test for buying is whether your compliance team can articulate, in one sentence, how your requirements differ from a vendor default. If they cannot, your problem is policy documentation rather than software, and a platform will simply automate an argument nobody has settled.

The point at which the requirements matrix becomes yours

What you need from a client is a function of four variables at minimum: entity type, jurisdiction of incorporation, the product being onboarded, and the risk rating that falls out. A Delaware operating company opening a deposit account is one branch. A Cayman fund with a nominee shareholder and a Luxembourg management company onboarding for prime brokerage is a different branch entirely, with look through to the investment manager, authorised signatory evidence and tax documentation that changes with the vehicle's classification.

Once that matrix is genuinely yours, a packaged product becomes a configuration exercise that never quite closes. The symptom is recognisable: relationship managers keep a personal spreadsheet of what a fund client really needs, because the system's list is either too long or missing three items. When the shadow spreadsheet appears, the system has stopped being the source of truth.

The second trigger is ownership. Under the customer due diligence rule, beneficial ownership turns on a percentage threshold plus a control prong, and in an institutional structure that means walking a graph and multiplying through the chain. Holding company owns sixty percent of an intermediate, the intermediate owns forty percent of the operating entity, a trust holds a slice and a general partner controls the fund that owns the rest. Analysts currently do this arithmetic in a document with an org chart pasted in as a picture, then screen the top entity and hope.

The third trigger is review backlog. Reviews driven purely by a cycle date guarantee two failures at once: effort spent refreshing files where nothing changed, and changes missed for eighteen months. If a finding has already been raised on periodic review, no amount of vendor configuration clears it, because the design assumption is wrong.

The costs that surface after the statement of work is signed

Screening fees. This is the one that catches almost everybody. Screening providers commonly price per screened entity per year. Screening only the top entity of a fund structure is one unit. Screening every node in the graph, which is what proper diligence on an intermediate vehicle and its controllers actually requires, multiplies your billable entity count several times over. Model that number before you design the ownership feature, because it changes the annual run cost far more than the build does.

Registry coverage. Automated ownership discovery is excellent where a national register publishes structured company data and unavailable where it does not. You will still need the manual path for the second group, so you are building two routes, not one, and the manual route is the one with the exception handling.

Document expiry. A W-8BEN-E generally expires at the end of the third calendar year after it is signed. A passport expires on its own date. A certified copy has a validity period set by your own policy. A file that was perfect at onboarding fails quietly on a fixed future date, and if expiry is not modelled as an event that opens work, your remediation queue rebuilds itself invisibly.

Downstream plumbing. An approved client has to become accounts, limits and entitlements in systems that were never designed to be fed by anything. That integration work is routinely underestimated because it is unglamorous and sits outside compliance's budget line.

Legacy migration. Importing ten thousand existing client files with unknown document quality, missing certification dates and structures recorded only as images is a project of its own. Scope it as one.

What each side costs over three years

These are Digital Heroes bands from more than 2,000 delivered projects. A first release covering the entity requirements matrix, a client facing document portal with reuse across entities, screening integration and a documented risk rating engine runs $90,000 to $200,000 and ships in 12 to 18 weeks. A full platform adding ownership graph modelling with registry data, perpetual review triggers, tax documentation handling, delegated client access and downstream account opening integration runs $250,000 to $600,000 across 8 to 16 months.

Entity type and jurisdiction count drive that range far more than client volume does. A firm onboarding four hundred simple corporates a year is a smaller build than one onboarding forty fund structures.

On the buy side, count the licence, the implementation partner, the internal configuration team you will second for a year, the annual screening fees under the entity multiplier above, and the analyst hours that remain because the portal did not remove them. Then set both totals against the exposure nobody prices: the cost of a remediation programme after a finding, which is measured in contractor day rates and executive attention rather than software.

There is a third option people forget to price, and it is usually the winner. Keep the screening data vendor, keep any registry discovery tool that already works, and build only the requirements matrix, the document store and the review engine above them. That hybrid typically lands in the first release band rather than the full platform band, because the expensive external data problems stay outside your scope entirely. It also fails gracefully: if the layer disappoints, your screening arrangements and your client files are untouched and you have lost a layer rather than a capability.

A ten file test

Pull ten institutional clients onboarded in the last year, deliberately choosing your most structurally complicated. Then time four things.

• How long from classification to a complete, correct requirements list reaching the client? If it took more than a day, the matrix is in people rather than in software.
• For each file, can you produce the ownership structure as data with an as at date, and show which nodes were screened? If the answer is an image in a Word document, a review three years from now will rebuild it from scratch rather than diff it.
• How many documents did you request that your organisation already held for that entity under another product? Every one of those is a client relationship cost you paid for nothing.
• How many of the ten are now overdue for review, and what triggered the review, a date or an event?

If eight of ten files pass, buy screening and keep your process. If four or more fail on the ownership and reuse questions, the requirements and evidence layer is the build, and it is a smaller build than the full platform people imagine.

Sequencing a programme that survives an examination

Build in the order an examiner reads. Requirements matrix first, because it is your policy expressed as software and everything downstream depends on it. Then the client portal with document reuse, since it produces the visible client experience improvement that keeps the programme funded. Then the ownership graph with screening on every node. Perpetual review triggers last, because they need the first three to be trustworthy before they can generate work anyone will action.

Insist on a written product requirements document before any code. In onboarding, that document is where compliance, operations and the front office finally agree what a complete file means for a fund with a nominee shareholder, and that argument is cheaper to have on paper. Digital Heroes works this way as standard, with a 50 plus person team, Fiverr Vetted Pro status and contracting through an India LLP, a US LLC or a UK LTD so the agreement and the intellectual property assignment sit in your own jurisdiction. That last point is not decoration for a regulated firm: your vendor risk assessment will ask which entity holds the contract. The team publishes openly on YouTube, where the channel carries 2.5 million subscribers.

Settle ownership before kickoff. You own the repository, the requirements rules and the client document store from the first commit. Any developer proposing to host your clients' formation documents inside their own tenancy should be declined on the spot.

If you would rather someone argued with your brief than agreed with it, Digital Heroes contracts through India LLP, US LLC and UK LTD entities, so the agreement and the intellectual property assignment sit under law your own advisers already read. The document is yours whichever way you go.