A proposal should explain what the system prepares, what the administrator must supply and how the team will decide whether it works. Include source access, review time, exceptions, running costs and the evidence needed for approval.
Make the internal workload visible before approval
A fund administrator considering AI may already have a clear target: preparing investor onboarding files, assembling a reporting pack or finding the evidence behind an outstanding query. The implementation still needs the team’s knowledge, access decisions and review time.
A proposal that describes only the provider’s tasks leaves part of the schedule and cost unexplained. Ask which people your firm needs to involve, what they must prepare and when their decisions are needed. That is part of the work you are approving.
Define the work product the team will receive
Consider an illustrative investor onboarding scope. The AI operating layer retrieves agreed documents around the administrator’s existing platforms, prepares a file for review and identifies information that is missing or inconsistent. The authorised team still decides whether the file is complete and whether the investor can be accepted.
The proposal should show what that prepared file contains: source references, document dates, unresolved questions and a destination for each exception. It should identify any proposed record updates or communications separately, with the required review before they take effect.
A useful scope names the participating team, fund or investor population, source systems and output. “Automate onboarding” is too broad to tell your colleagues what will change on Monday morning.
Agree what the administrator must provide
The provider needs someone who understands the workflow, someone who can make the operating decision and appropriate technical and control participation. One person may hold several responsibilities, but the responsibilities should remain clear.
List the documents and system access required, the permission boundary, representative test cases and the expected availability of reviewers. Identify data that needs cleaning or a decision about which source is authoritative. Do not hide that work inside an assumption that the client will provide everything promptly.
For each dependency, record the owner and the consequence of a delay. Ask whether an unavailable connection can be replaced with a controlled export and whether that changes the scope, maintenance effort or security assessment.
Use acceptance tests that resemble the working file
Agree the expected result before the demonstration. For the illustrative onboarding scope, an ordinary complete file should produce a preparation pack with accurate source references and no invented missing items.
A file with an absent or inconsistent document should carry the issue into the agreed review route, rather than appear complete. A restricted record should remain inaccessible to a user who lacks permission, including through generated text or cross-references.
Ask a reviewer to use each output and record what needs to be reopened, corrected or reconstructed. Compare total preparation and review time with the current process. These tests are proposed evaluation scenarios, not evidence of delivered Halyard results.
Separate delivery costs from the costs of using it
Understand what the implementation fee covers and what continues after launch. That may include model usage, hosting, support, connection maintenance and the firm’s own review effort. The actual costs depend on the selected design and agreed scope.
Ask who investigates an incorrect output, who can change the configuration and what happens when a source system changes. Confirm how the team continues the work if the capability is unavailable. Those questions affect the operating case as much as the first demonstration.
Approve a clear starting scope
When the first workflow and its dependencies are understood, the firm may be ready to approve an implementation. When the business case, access or control requirements remain uncertain, an assessment can resolve those questions before a larger commitment.
Either route should end in a concrete decision. The proposal needs a defined output, a realistic share of client work and an agreed way to judge the result.
A proposal should let your team plan the work
Your colleagues should be able to identify what they will supply, review and maintain without translating broad promises into a plan themselves. That clarity makes it easier to compare providers and to protect service delivery while the implementation takes place.
Related Halyard resources
Founder of Halyard, an AI implementation company helping financial services firms find and implement practical AI safely.
