Bank-grade KYB RFP requirements: which vendors qualify in 2026?

Most KYB vendor pitches look the same. Trust badges on a security page, a mention of SOC 2, a list of data sources. During an RFP, that surface-level presentation collapses fast. Bank procurement teams don't accept marketing claims as evidence, they ask for the actual SOC 2 Type II report, the audit period, the subprocessor list, and a sample exported audit log.

If you're running a bank-grade KYB evaluation right now, this is the rubric that separates genuinely qualified vendors from those who clear the marketing bar but fail the documentation test.

What "qualified" actually means in a bank RFP

KYB (Know Your Business) is categorically different from KYC. KYC verifies a natural person. KYB verification traces a legal entity through its ownership structure and then runs KYC on each ultimate beneficial owner and key controller. That layered complexity is exactly why banks treat KYB vendors as third-party risk, not just product vendors.

A qualified vendor needs to demonstrate two things simultaneously: functional KYB capability and security/compliance evidence. The requirements below are categorized as Must-have (non-negotiable for bank RFPs), Should-have (expected by most procurement teams), and Nice-to-have (differentiators that break ties).

Requirement 1: Entity verification plus full UBO resolution

Registration checks alone don't qualify. Banks need corporate identity verification and ownership mapping down to the natural persons who ultimately control the entity.

The 25% threshold is the most common starting point: FinCEN's CDD Final Rule explicitly requires US banks to identify and verify individuals who own 25% or more of legal entity customers. The EBA's revised AML/CFT risk factor guidelines (published March 1, 2021) tightened similar expectations across European institutions. FATF's beneficial ownership guidance frames the whole exercise as a risk-based obligation, the point is identifying who actually controls the entity, not just who appears on the register.

Multi-tier ownership structures are the RFP pain point nobody talks about enough. A holding company owns a subsidiary which owns the operating entity. If your vendor's UBO verification only resolves one layer, you have a gap. Equally important: the verification must be evidence-based (corroborated through independent registry and document sources), not just self-declared.

Classification: Must-have.

Requirement 2: Sanctions and PEP screening that's operationally usable

Global sanctions and PEP coverage is table stakes. What banks actually evaluate is how the screening engine handles matching and what the operational workflow looks like on top of it.

Fuzzy matching, alias resolution, and transliteration handling determine whether your analysts spend their days clearing false positives or reviewing genuine risk. An engine with poor tuning will generate false positive rates above 90%, which is the industry baseline McKinsey has cited for AML operations broadly. A well-configured PEP and sanctions screening engine should land materially below that.

Beyond match quality, RFPs increasingly specify lifecycle screening requirements. One-time screening at onboarding isn't sufficient. Banks expect daily re-screening with alert queues, documented decisioning rationale, case management workflows, and audit-ready records of every hit and override. If a vendor can't demonstrate that workflow end-to-end, score them down.

Classification: Must-have.

Requirement 3: SOC 2 Type II (and why Type I doesn't clear the bar)

SOC 2 Type I confirms controls were designed correctly at a point in time. Type II confirms they operated effectively over a period, typically six to twelve months. Banks require Type II. Full stop.

The evidence themes banks typically ask for within the report: security/access controls, confidentiality and privacy, processing integrity, and availability. They also review the audit period dates and any qualified opinions or exceptions. A SOC 2 Type II report with a stale audit period (more than 18 months ago) or scope that excludes the vendor's production KYB data flows is a red flag.

Among the vendors commonly appearing in KYB RFPs: Alloy's security page confirms SOC 2 Type II and ISO 27001, citing AES-256 encryption, TLS 1.2 in transit, and annual penetration tests on AWS infrastructure. Trulioo's compliance page also leads with ISO 27001 and SOC 2 Type 2 alongside a structured information security program. Sumsub's Trust Center lists SOC 2 Type 2 alongside SOC 1 Type 1, PCI DSS, and multiple ISO certifications. Middesk has SOC 2 Type II noted in comparative market context.

The gap across all four: none publish downloadable report summaries, scope statements, or AOC excerpts on public pages. Buyers must request documents to assess actual scope and audit period, which is exactly the right move regardless.

Classification: Must-have (report on request); ISO 27001 as Should-have.

Requirement 4: Data governance, retention, deletion, encryption, residency

This is where many vendors stumble on specifics. Banks ask pointed questions:

• What are the retention periods for KYB evidence, UBO records, and audit logs?

• How is secure deletion handled when records reach end of retention?

• What encryption is applied in transit and at rest, and who holds the keys?

• Where does data physically reside, and what cross-border transfer mechanisms apply?

For multi-country onboarding programs, data residency is often the deciding factor. A vendor who can only confirm "AWS infrastructure" without specifying regions or EU Standard Contractual Clause coverage creates a procurement blocker.

Classification: Must-have (encryption + retention policy); residency specifics as Should-have for cross-border programs.

Requirement 5: Immutable audit trails with decision provenance

Audit trails are what a bank shows regulators when asked to justify an onboarding decision. The requirement isn't just "we log things." It's:

• What data was queried, from which sources, at what timestamp

• Which analyst reviewed the case and what action they took

• What the match rationale was for any screening hit

• Whether an override occurred and the documented reasoning

• The final decision and policy version in effect at that time

Banks should ask for a sample exported audit log, the actual fields and format, during vendor evaluation. A vendor who can't produce one on request probably doesn't have the depth of auditable case management a bank-grade evaluation requires.

Classification: Must-have.

Requirement 6: Subprocessor transparency and right-to-audit

KYB vendors depend on upstream data providers: company registries, UBO feeds, sanctions list providers, PEP databases, adverse media sources. Banks need to know who those subprocessors are and what contractual protections govern their use of customer data.

A complete subprocessor list, DPA terms, and right-to-audit clauses in the master services agreement are standard expectations. Operationally, redundancy and fallback across data providers also matters. A vendor relying on a single registry feed for a given market creates regulatory continuity risk if that feed goes down. Smart routing across providers with built-in fallback is a meaningful differentiator.

Classification: Should-have (subprocessor list); redundancy/fallback as Should-have.

Vendor qualification matrix

The table below summarizes publicly available evidence from vendor security and compliance pages. It does not substitute for actual document review, bank RFP qualification depends on the requested artifacts, not marketing claims.

Every vendor in this space gates their actual compliance evidence behind NDAs and request flows. That's normal. What separates them is how quickly they can produce the artifacts and how complete those artifacts are.

How to run vendor due diligence in four steps

Step 1: Map your RFP clauses to evidence artifacts. Take each control requirement and identify the specific document that satisfies it. SOC 2 Type II report, AOC or executive summary, retention/deletion policy, encryption statement, subprocessor list, sample audit log export. Don't accept a security webpage as a substitute.

Step 2: Request the documents before shortlisting. Any vendor who won't provide a redacted SOC 2 report or a sample audit log under NDA before a commercial conversation is giving you signal about their operational readiness.

Step 3: Run a proof-of-workflow. Give each vendor a realistic scenario: multi-tier ownership structure with a PEP in the chain, a sanctions hit requiring an override, and a periodic re-review 12 months later. The workflow, case management depth, and audit trail produced tell you more than any security page.

Step 4: Score against your must-have controls, not feature lists. A vendor with 200 integrations and a thin audit trail fails a bank RFP. A vendor with fewer integrations but complete, time-stamped, policy-versioned decision records passes.

Why Duna is built for bank-grade KYB evaluations

Duna's architecture was designed around the exact requirements above. The policy engine translates compliance logic into code, every data collection decision, risk score, and verification step is driven by explicit policy, which means audit trails carry full data provenance: what was collected, from which source, and under which policy version. That's what regulators ask for.

On the screening side, Duna runs daily PEP, sanctions, and adverse media screening with lifecycle monitoring built into the compliance workflow, not bolted on as an afterthought. The data platform orchestrates across global and local providers with smart routing and redundancy, so a single-source failure doesn't create a regulatory gap. For multi-country programs, 210+ local registries and 7+ languages mean UBO resolution works where your customers actually operate, not just where registries are easy.

For banks specifically, Duna's KYB for banking offering is built to banking-grade regulatory standards, with lifecycle compliance, re-KYB automation, and full case management from a single platform. The AI agents handle document verification and periodic reviews, multiplying analyst throughput without degrading the audit record quality.

For an RFP response, the right posture is to provide evidence artifacts proactively: the SOC 2 report, data governance documentation, and a sample audit trail from a live case workflow. Duna is equipped to deliver all three.

FAQ: what RFP buyers ask

Do we need SOC 2 Type II or is Type I enough? Type II is the bank-grade standard. Type I only confirms point-in-time design adequacy. Ask for the Type II report and check the audit period, anything older than 18 months should prompt a follow-up.

What must we require for UBO resolution? At minimum: resolution to natural persons, evidence-based verification (not self-declaration), support for multi-tier structures, and a threshold consistent with your regulatory regime (commonly 25%, per FinCEN's CDD Final Rule).

How should we evaluate sanctions/PEP screening quality? Ask for the vendor's false positive rate in a comparable deployment, their match tuning methodology, and a live demo of the alert-to-decision workflow. Then check whether the audit trail captures the rationale for every hit, clear, and override.

What evidence should we request for audit logs and data retention? Request a sample exported case log (fields and format), the written retention and deletion policy with timelines, and the encryption statement (in-transit and at-rest, with key management detail). These three documents answer most bank procurement questions before a security review call is even needed.