A good AML RFP does two things: it tells vendors enough about the institution to propose a realistic solution, and it forces each vendor to answer the same requirements in a comparable form. A weak RFP does neither. It asks broad questions, attracts broad answers and leaves the evaluation team to discover important differences during demonstrations.
Section 1: business and regulatory context
- Business lines and regulated entities in scope.
- Customer and counterparty types.
- Key jurisdictions and cross-border exposure.
- High-level financial-crime risk profile.
- Current control architecture and systems being retained.
- Target go-live, project constraints and expected growth.
Section 2: screening requirements
- Individual and corporate screening.
- PEP and sanctions data requirements.
- Adverse media and regulatory/law-enforcement sources where required.
- Original-script name support and matching configuration.
- Single, batch and API screening requirements.
- Due-diligence decisions, whitelisting and re-screening/monitoring.
Section 3: KYC, KYB and customer risk
- Identity verification requirements by market/customer type.
- Business verification and registry evidence.
- Beneficial ownership requirements.
- Customer risk factors and risk-scoring logic.
- Periodic and trigger-based review requirements.
- Source of funds/wealth evidence where applicable.
Section 4: transaction monitoring
If transaction monitoring is in scope, define the transaction types, expected volumes, latency, rule/scenario requirements, customer profiling, alert workflow, tuning, historical lookback and reporting. If it is out of scope, define the integration needed with the retained monitoring engine.
Section 5: workflow and evidence
- Queue and assignment requirements.
- Escalation and approval workflow.
- Comments, supporting documents and rationale capture.
- Audit history and access logs.
- Operational and management reporting.
- Export requirements and historical evidence retrieval.
Section 6: integration and technical architecture
- API requirements and authentication.
- Batch/file options.
- Upstream/downstream systems.
- Expected volumes and performance.
- Service regions/data location requirements.
- SSO and user provisioning where required.
- Error handling, retry and reconciliation.
Section 7: security and resilience
Have security teams provide the organisation’s standard assurance requirements. Ask vendors to separate certifications or independent assurance from product features. Include access control, encryption, logging, vulnerability management, incident processes, backup/recovery and subcontractor considerations relevant to your policy.
Section 8: implementation
- Proposed implementation methodology.
- Responsibilities by vendor/client.
- Data migration approach.
- Configuration workshops.
- Integration/testing plan.
- Training and documentation.
- Cutover and hypercare.
- Assumptions and dependencies.
Section 9: support and product lifecycle
- Support hours and escalation.
- Release/change management.
- Product roadmap governance.
- Configuration support.
- Major-version policy.
- Data export and exit assistance.
Section 10: commercial response
Require vendors to state the pricing basis and assumptions rather than only a total. Ask for implementation, recurring fees, optional modules/data, support, non-production environments, volume tiers and any expected third-party costs. Request a multi-year view so cost comparisons reflect growth.
Require a standard response template
For every material requirement, ask the vendor to state whether the capability is standard, configurable, requires professional services, requires custom development or is not currently available. Require a short explanation and evidence reference. This avoids a common problem where “yes” can mean anything from available today to potentially achievable through a future project.
Plan the evaluation process before issuing the RFP
Define the evaluation team, scoring rules, mandatory gates, clarification process, demonstration scenarios and commercial evaluation before responses arrive. Vendors should not be able to influence the scoring model after seeing where they are strong or weak. Keep a record of material clarifications so all bidders are evaluated on the same information.
Use three response types
| Requirement type | How vendors respond |
|---|---|
| Mandatory | Comply / does not comply, with evidence. |
| Scored | Describe approach and provide demonstration/reference evidence. |
| Informational | Explain product/vendor context without affecting the compliance gate. |
Separate the written RFP from the demonstration stage
Use the written response to confirm scope, architecture, security and contractual facts. Use demonstrations for workflows that need to be seen. Use a proof of concept only for material uncertainties that remain after those stages. This prevents the procurement process from becoming one long sales demonstration and preserves comparability.
Ask for evidence, not adjectives
Replace “describe your market-leading matching capability” with a scenario the vendor must demonstrate. Replace “describe your reporting” with named reports and evidence the institution needs to retrieve. The RFP should reduce interpretation.
Use this structure as the baseline for a MemberCheck RFP and require the response to map each requirement to standard capability, configuration or custom work.
