The Statement of Work: Turning a Winning RFP Into a Contract That Holds

The selection is the part everyone remembers. Eight weeks of requirements workshops, a scored evaluation, a proof of value, a shortlist debate and a recommendation paper that goes to a committee. Then the winner is announced, the project team exhales, and the file moves to legal for what everyone describes as paperwork. That handover is where a large proportion of financial crime technology programmes quietly lose the thing they bought.

The statement of work converts a bid into an obligation. Everything the vendor said during the process has exactly the status the contract gives it, and in most transactions the contract gives it none. The performance figures quoted in the response, the named implementation lead, the tuning support, the integration described as standard, the feature arriving next quarter: unless each appears as a defined, dated, measurable commitment in a schedule, it is a sales artefact. Six months later, when the programme is behind and the model is underperforming, the institution discovers its leverage evaporated at signature.

This post is about that stage: how to turn the winning response into a contract that holds, and how to read what comes back from the vendor's legal team and from your own. It assumes a competitive process has been run and a proof of value completed, which the archive covers separately. The subject here is narrower: the drafting, and the few clauses that decide whether the institution owns its outcome or merely rents optimism.

Where Procurement Goes Wrong

The commonest failure is the silent gap between the bid and the contract schedule. A tender response of two hundred pages, full of specific commitments, is superseded by a master services agreement and an order form of thirty pages that reference none of it. Nobody decides to discard the commitments; they are never transcribed, because whoever drafted the contract was not in the evaluation and whoever ran the evaluation does not read contracts. The institution ends up holding a generic software licence, having selected the supplier on assertions that now live only in a file on a shared drive.

The near relative is the clause that gestures at the response without attaching it. Wording along the lines of "the Services shall be provided substantially as described in the Supplier's response" appears in a large share of the agreements we review. It looks like protection and usually is not: the response is often not appended, so there is no agreed version; the order of precedence clause almost always ranks the supplier's terms above any incorporated document; and "substantially as described" is not a standard a dispute can be run on.

The third failure is acceptance defined as go-live. Acceptance is the most valuable lever the institution holds, because it is the point at which payment, warranty periods and remedies attach. Defining it as deployment into production means the vendor is paid in full for a system that is installed and switched on, irrespective of whether it detects anything. We regularly see programmes where acceptance was signed at cutover, performance was found materially below the proof of value result months later, and the only remaining route was a change request the institution had to pay for.

Three further gaps recur. Roadmap items are accepted verbally and appear nowhere, so the capability the business case depended on arrives, if at all, at the vendor's convenience. Tuning, threshold optimisation and model retraining are left undefined and then quoted as a change request at the moment the typology shifts. And ownership is left silent: who owns the tuned thresholds, the labelled outcome data, the feature definitions, the trained model artefacts and the case history. Institutions discover at exit that what they can extract is raw input, and that everything derived from it, where the accumulated value sits, is characterised by the supplier as its own intellectual property.

Running the Stage Properly

Begin by treating the statement of work as an output of the evaluation rather than a successor to it. Before the recommendation paper goes to committee, the evaluation team should produce a commitments register: every material statement made by the winning bidder in the response, the demonstrations, the clarifications and the proof of value report, with a source reference and a proposed contractual home. That register becomes the drafting instruction. It costs a few days and it is the difference between a contract built on the selection and one built on the supplier's template.

Then push the substance into named schedules rather than recitals. Four schedules do most of the work. A performance schedule setting out detection commitments in the institution's own terms: alert volume at a stated threshold on a stated population, precision and recall or their operational equivalents, false positive rate bands, latency at defined percentiles under peak volume, and the measurement method and cadence by which each is assessed in production. An implementation schedule naming individuals rather than roles, committing days by phase, setting dated milestones and stating the consequence of slippage. An acceptance schedule containing the test protocol itself. And a service schedule with availability, incident severity definitions, response and restoration targets, support hours in the institution's time zones, and service credits calibrated to matter.

Define acceptance against the proof of value protocol, reusing that protocol verbatim. If the pilot demonstrated a specified uplift on a specified historical data set under a specified configuration, acceptance is the reproduction of that result in production within a defined window, measured the same way. This is the most effective drafting move available to a buyer, because it is manifestly fair: the vendor is asked to deliver exactly what it demonstrated. Attach the remedies that give it force, meaning staged payment with a meaningful proportion held until acceptance, a defined remediation period, and a termination right with refund if acceptance is not then achieved. Roadmap items should be handled the same way, as dated deliverables with a consequence for non-delivery, or removed from the business case.

Write tuning and change into the service description rather than leaving them to change control. State how many threshold and rule changes are included per period, the turnaround, who may request them, whether the institution can make them itself, how often models are retrained, on whose data, who approves the retrained version, and what the documentation pack contains. A financial crime system that cannot be retuned quickly without a commercial negotiation will be out of date within a year.

Finally, negotiate exit at signature, because it cannot be negotiated later, and the regulatory hooks here are real rather than decorative. The EBA guidelines on outsourcing arrangements require the written agreement to specify service descriptions with quantitative and qualitative performance targets, data location and processing, access and audit rights for the institution, its auditors and the competent authority, sub-outsourcing conditions, termination rights and, for critical or important functions, a documented exit strategy with a transition period. DORA imposes an overlapping and in places stricter set of mandatory contractual provisions for ICT third party arrangements, including precise performance targets, incident assistance, data availability commitments, inspection rights, notice periods and exit strategies. The FCA and PRA operational resilience regimes require the firm to remain within impact tolerance for its important business services and to be able to exit under stress. Put concretely: extraction format and frequency for all data including derived and labelled data, the tuned configuration and model artefacts, transition assistance at pre-agreed rates, and certified deletion on termination.

Evaluating What You Get Back

Read the returned draft for what moved, not for what survived. Vendors rarely refuse a commitment outright; they soften it. Watch the transformations: an obligation becomes a target, a target becomes an objective, "shall" becomes "shall use commercially reasonable endeavours", a figure acquires "approximately", a date acquires "estimated", and a measurement method becomes "as mutually agreed", which means agreed after you have paid. Each is a negotiating position rather than a fixed constraint, and the right response is to ask what evidence supports the softening. A supplier confident in its proof of value result has no principled reason to refuse to be measured against it.

Check the architecture of the agreement as carefully as the wording. The order of precedence clause determines which document wins, and a stack ranking the supplier's standard terms above the schedules quietly neutralises everything the drafting achieved. Confirm that any incorporated response is attached and version-identified. Read the liability provisions against the performance commitments: a service credit regime capped at a fraction of monthly fees, stated as the sole remedy, converts a detection failure into a small discount. Confirm that the contracting entity is the entity that will perform the work, that sub-outsourcing including cloud infrastructure and model providers is disclosed, and that audit rights extend down that chain, since that is where DORA and the EBA guidelines are explicit and where vendor paper is usually silent.

Read your own legal team's output with the same discipline. Internal counsel optimise for enforceability and risk allocation, and will not know that a stated false positive rate is meaningless without a stated population and threshold. The technical owner has to review the performance and acceptance schedules line by line and ask one question of each commitment: if the vendor delivered the minimum this clause permits, would we be satisfied. Anything failing that test is not yet drafted. Ask the reverse question of the institution's own obligations too, because most acceptance disputes turn on a dependency the buyer failed to meet.

Conclusion

The contract is not the administrative tail of a selection process. It is the only surviving record of what was actually bought, and it is read in anger only when something has gone wrong, by people who were not present for the conversations that led to it. Everything that mattered during evaluation must be visible to somebody with no memory of the process, or it does not exist.

Institutions that do this well share one habit: the people who ran the evaluation stay involved until signature, and the commitments register travels with the deal. This is neither a legal nor a procurement exercise. It is the point at which a persuasive response becomes an enforceable obligation, and the hour spent defining acceptance against the proof of value protocol is worth more than the weeks spent scoring the tender before it.

Suggested Next Steps

• Require a commitments register as a mandatory output of every financial crime technology evaluation, listing each material bid statement with its source and its proposed contractual home, and make it the drafting instruction for the statement of work.

• Adopt a standard schedule set covering performance, implementation resourcing, acceptance and service levels, with detection commitments expressed as measurable figures against a defined population, threshold and measurement method.

• Define acceptance as reproduction of the proof of value result in production within a stated window, and attach staged payment, a remediation period and a termination right with refund to it.

• Negotiate exit, data extraction including derived and labelled data, model artefact portability and transition assistance rates before signature, and check the resulting agreement against the EBA outsourcing guidelines, the DORA contractual requirements and your operational resilience exit obligations.

Sources: EBA outsourcing guidelines, DORA, Financial Conduct Authority, Prudential Regulation Authority, HM Treasury, Payment Systems Regulator, Wolfsberg Group, TrustSphere Risk Index, April 2026.

TrustSphere helps financial institutions design and deploy intelligent fraud and financial crime detection solutions. Visit www.trustsphere.ai