Expert Network Engagement Management Software: How Do You Prove Which Restrictions Applied at the Moment That Call Was Booked?

Why an expert call is a compliance event before it is a scheduling event

A research analyst wants to speak to someone who understands hospital purchasing of a particular device category. The network finds a candidate: a former category manager who left the relevant manufacturer eight months ago and now consults. That single fact pattern raises several questions that must be answered before a calendar invite exists. Does this client's policy allow former employees of a covered company, and within what look back period. Is the manufacturer on this client's restricted list this week, and was it last week when the project started. Is the company inside a quiet period around results. Does the expert's own employer or separation agreement prohibit the discussion. Has the expert given the attestations this client requires, in the current version. Does this client permit recording, and does this expert consent.

Every one of those has a different answer for a different client, and several change over time. Most networks and internal research desks handle this with a compliance checklist, an email approval, a scheduling tool and a spreadsheet of restrictions per client. It works right up to the moment somebody has to reconstruct, months later, exactly which restrictions were in force when a specific call was booked, and prove it.

The industry learned the shape of this risk in the enforcement actions that followed expert consultations in the early 2010s, and the compliance posture across investment firms hardened permanently as a result. What did not modernize at the same pace was the tooling. The controls exist. They exist as documents and habits rather than as a system that can produce evidence on demand.

Problem 1: employment history is a timeline, and most systems store a job title

Restriction rules are almost always time bounded. No current employees of a covered company. No former employees within six months, or twelve, depending on the client. No one who held a role with access to the relevant information during the period the research covers. Those rules cannot be evaluated against a field that says current employer.

What a build does is model employment as a set of time bounded records with employer, role, seniority, function and any relevant access indication, resolved against a company entity graph so a subsidiary and its parent are recognized as related. Then a restriction rule becomes a query over the timeline rather than a judgment call by a coordinator. Same expert, two clients, two different answers, both explainable. This is the core data structure of the whole product, and getting it wrong caps everything built on top.

Problem 2: restrictions are per client, per project and constantly changing

A hedge fund client bans anyone who has worked at a set of covered companies. A long only manager restricts by sector during a live position. A corporate client running competitive research bans current employees of named competitors outright. A consulting client applies its own end client conflict rules. Restrictions change weekly, sometimes mid project, and a booking made yesterday under yesterday's list may be non compliant today.

A build treats restriction policy as versioned data, ingested from client provided lists on a schedule rather than typed in by a coordinator from an email. Evaluation happens twice at minimum: at booking, and again shortly before the call, with the second evaluation able to cancel or escalate if the position changed. Every evaluation writes a frozen decision record: which policy version, which list version, which expert timeline facts, which rules fired, who approved any override and on what stated basis. That record is the actual product from a compliance officer's point of view. Everything else is logistics.

Problem 3: attestations, chaperones and recordings are handled in four disconnected tools

Before the call, an expert signs consultation terms and attestations covering confidentiality, non disclosure of material non public information, absence of a current employment conflict, and any client specific undertakings. Some clients require a chaperone on the line. Some require recording, some prohibit it, and consent rules vary by the jurisdictions of the participants, which is a real constraint when the expert is in one country, the analyst in another and the chaperone in a third.

Doing this across an e-signature tool, a calendar, a conferencing platform and a shared drive means the evidence of a compliant call is scattered across four vendors with no single record. A build binds them: the engagement record holds the attestation versions actually signed, the scheduling decisions, the chaperone assignment, the recording policy applied and why, the consent captured from each participant, and the retention rule that will govern the resulting recording or transcript. Deletion happens on schedule by policy rather than by someone remembering. If a client asks what happened on a call from fourteen months ago, the answer is one record with everything attached.

Problem 4: Inex One solves the buyer's problem, not the operator's

Inex One is a real product and a sensible one. It sits on the buyer side, letting an investment firm or consultancy manage expert spend, projects and multiple network relationships in one place, with visibility across suppliers. If your problem is that your research team uses four networks and nobody can see total spend or consultation volume, that is exactly the tool.

It is not built to run a network's own operation. Expert sourcing and profile maintenance, client specific screening at the point of booking with an evidentiary trail, chaperone operations, recording policy enforcement, and above all the payment and tax machinery for paying thousands of individuals across many countries: those are the operator's problems and they sit outside a spend management layer. Networks that try to run on buyer side tooling end up with the compliance and payment functions back in spreadsheets, which is where the risk actually lives.

If you are the buyer, use a buyer side tool. If you are the operator, or an internal research desk that has effectively become an operator, the build case is about screening evidence and payments, and neither is available off the shelf in a form that matches your policies.

Problem 5: paying thousands of individuals across borders is its own product

Experts are individuals, not vendors. They are paid per consultation at negotiated rates, sometimes with minimums, sometimes in kind through charitable donation options that some employers require. They live everywhere. Payment means collecting tax documentation appropriate to the jurisdiction, screening against sanctions and politically exposed person lists, selecting a payment rail that works in that country at a sensible cost, handling failures and re-issues, and producing year end reporting where it is required.

Networks routinely underestimate this and discover that a meaningful share of operations time goes to chasing tax forms and failed payments. A build handles it as a pipeline: onboarding collects identity and tax documentation with validation, screening runs before first payment and periodically after, rate cards resolve the amount owed automatically from the completed engagement, and payments batch across rails with reconciliation and clear failure handling. Experts get a portal showing their engagements and payment status, which removes a large share of inbound email. None of this is glamorous. It is where the operational cost sits.

What this costs and how long it takes

A first release covering the expert master with employment timelines and entity resolution, the client restriction rule engine with versioned policy ingestion, dual evaluation at booking and pre call, attestation capture and the frozen compliance decision record runs $70,000 to $150,000 and ships in 12 to 18 weeks in our delivery experience. A full platform adding scheduling with time zones and chaperone assignment, conferencing and recording integration with policy enforcement, transcripts with retention rules, sanctions screening, multi country payments with tax documentation and an expert portal runs $180,000 to $450,000 across 6 to 12 months.

What drives price up specifically in this category: the number of payment countries and rails, since each has its own documentation, currency and failure behavior. Recording and consent handling across jurisdictions, which is a legal design question before it is an engineering one. Client restriction list ingestion, because every client will send a different format and some will send a PDF. Transcription and translation volume if consultations run in several languages. And integration with client side systems, if large clients want their research management platform to see engagements directly.

What keeps it down: the expert timeline, the rule engine and the decision record. That is the compliance spine, and it is what a regulator or a client's compliance team will ask about.

Build versus buy, and when buying is right

Do not build if you are a buyer running occasional expert calls through one or two networks. The networks carry the compliance obligation for their own screening, and a buyer side tool such as Inex One covers spend and project visibility at a fraction of the cost. That is the correct answer for most investment firms below a certain research volume.

Build when two or more of these are true. You operate an expert network, meaning the screening obligation is yours rather than a supplier's. You run an internal research desk that sources experts directly and has therefore become an operator without acknowledging it. You pay experts across more than a handful of countries and operations time is disappearing into tax forms and failed payments. Your clients impose different restriction policies and you currently reconcile them by hand. Or you have been asked, by a client's compliance team or an examiner, to evidence which restrictions applied to a specific historical booking and it took days to answer.

The honest tipping point is the evidence question. If you can answer it in minutes with a record rather than a reconstruction, you do not need this. If answering requires assembling emails, you are one examination away from a bad month.

How to choose a developer for expert network software

Ask them to model a restriction rule that excludes anyone employed by a covered company within the last twelve months, including subsidiaries. Someone who has done this will immediately want employment as time bounded records and companies as a resolved entity graph. Someone who proposes a current employer field and a blocklist has not understood the problem and will build something that quietly fails at exactly the cases that matter.

Ask what gets frozen at the moment of booking. The right answer includes policy version, restriction list version, the expert timeline facts relied on, the rules that fired, and the identity and stated basis of any override approver. Without that, you have a workflow tool rather than a compliance system.

Ask how recording consent varies by participant jurisdiction and how the system enforces it. If the answer is a single global toggle, the design has not met the reality of a call with participants in three countries.

Ask what payment rails and tax documentation flows they have actually implemented, by country. Paying individuals internationally is where these projects overrun, and general experience with payment providers is not the same as having shipped expert payouts with documentation collection and sanctions screening.

Ask who owns the code and settle it in writing before kickoff. You should own the repository, the cloud accounts and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. This system holds your compliance evidence, and compliance evidence should never live somewhere you cannot reach without a vendor's cooperation.