What Is a DDQ (Due Diligence Questionnaire)?

For a fintech, clearing a DDQ is usually the gate between signing a partnership and actually going live on payment rails. Unlike a sales questionnaire, a DDQ is a risk document. The reviewing institution is building a file it may later have to defend to its own examiners, so answers are expected to be specific, current, and backed by evidence a third party can inspect.

Who sends a DDQ, and when?

DDQs arrive from the party carrying regulatory responsibility for the relationship:

• Sponsor banks, before granting a fintech or payment facilitator access to payment rails
• Partner banks and BaaS providers, during onboarding and then on a recurring review cycle
• Enterprise and financial-services buyers, as part of vendor onboarding
• Investors and fund allocators, in a different but structurally similar form

The trigger is almost always a decision point: a new banking relationship, a renewal, a material change to the product, or a periodic re-review. That timing is what makes DDQs commercially painful — they land precisely when a deal is closest to closing.

What a DDQ contains

Contents vary by institution, but most bank DDQs cover a recognisable set of domains:

Most questions ask for a narrative answer and a supporting document. That pairing is the defining feature of a DDQ: a claim without attached evidence is usually treated as unanswered.

The evidence behind the answers

The documents a DDQ leans on are typically ones a fintech already has:

• A SOC 2 report — usually Type II, because it tests whether controls operated over a period rather than existed on one day
• PCI DSS documentation, where cardholder data is in scope
• Written information security, access control, and incident response policies
• AML/KYC program documentation
• A recent penetration test report
• Prior approved DDQ and RFP responses

The recurring failure is not missing evidence — it is scattered evidence. The SOC 2 sits with Security, the policies with Legal, the prior answers in someone's inbox. Each new questionnaire restarts the same retrieval work.

Why freshness matters more than completeness

A subtle trap: evidence that exists but has aged out. Stale evidence — a penetration test older than the reviewer accepts, a lapsed policy, an expired certification — often causes more rework than a genuine gap, because it surfaces late, after the answer has already been submitted and reviewed.

Reviewers tend to check dates before they check content. An answer citing a twelve-month-old test in an institution that expects one within the year does not fail on substance; it fails on currency, and it comes back.

DDQ vs RFP

The two get conflated because both are long questionnaires answered by overlapping teams, but they serve different purposes:

The practical consequence: an RFP answer is written to persuade, a DDQ answer is written to survive review. Reusing marketing copy in a DDQ is a common and expensive mistake — assertions that read well in a proposal become unsupported claims in a risk file.

How teams answer DDQs today

Most fintechs start manually: a spreadsheet, a shared doc, and a chain of internal reviewers. That works for the first questionnaire and degrades from there, because each new DDQ asks substantially the same questions in a different order and format.

Three approaches are common:

1. Manual assembly — accurate if the team is disciplined, but slow and hard to sustain as volume grows
2. Generic RFP tooling — faster at reuse, but usually indifferent to whether the underlying evidence is current
3. Evidence-grounded automation — drafts answers from approved source documents and carries citations and freshness state through to the reviewer

What good automation preserves

Automation helps with retrieval and drafting. It should not touch the two things that make a DDQ defensible:

• Citations. Every answer should point to a specific source document, ideally to the page. An answer nobody can trace is an answer a reviewer has to re-derive.
• Human approval. A person accountable for the claim signs off before anything is exported. Speed that removes the approval step trades a slow problem for a serious one.

If a tool generates fluent answers without a source and without a reviewer on record, it has automated the wrong half of the work.

Key takeaways

• A DDQ is a risk document, not a sales document — precision beats persuasion
• Answers are expected to pair a narrative with inspectable evidence
• The bottleneck is usually retrieval and freshness, not missing controls
• Reuse is the largest available win, because questions repeat across institutions
• Citations and human approval are what make a response defensible — keep both

Related

• DDQ automation: the complete guide — the pillar guide to automating this work
• DDQ vs RFP — why the same answer succeeds in one and fails in the other
• DDQ template & examples — the eight sections, with a worked answer
• Compliance & DDQ glossary — definitions for every term above
• Frequently asked questions — how RAVIQ drafts and cites answers