Six Acquirer-Readiness Gaps That Can Delay a Fintech Application
Why Most Fintechs Only Find Out During Due Diligence And How to Get Ahead of It
Acquirer due diligence can expose documentation, control and ownership gaps that were less visible during product development. Discovering one does not automatically mean rejection, and there is no universal three-to-six-month minimum delay. It can, however, create additional questions, remediation work or a slower onboarding decision.
There is also no single public checklist used identically by Barclaycard, Worldpay, Lloyds Cardnet and every other acquirer. Underwriting requirements vary according to the applicant's business model, jurisdictions, products, transaction volumes, customer profile, fraud exposure and role in the payments chain.
What can be prepared in advance is the evidence behind six areas that commonly matter to payment risk: PCI DSS validation, fraud and dispute performance, operational resilience, financial-crime controls, security testing and sanctions compliance.
The aim is not to predict an acquirer's decision. It is to make your answers accurate, supported and easier to review.
Why acquirer due diligence goes beyond the product
An acquirer enables merchants to accept card payments and manages obligations arising from its participation in the card schemes. It therefore needs to understand the commercial and operational risk associated with a prospective merchant, platform or payment facilitator.
The review is unlikely to focus only on whether the product works. Depending on the relationship, the acquirer may consider matters such as:
the legal entity, ownership and business model;
products, markets, customers and prohibited or higher-risk activity;
expected transaction volumes and values;
fraud, disputes, refunds and reserves;
PCI DSS responsibilities and validation evidence;
financial-crime and sanctions controls where relevant;
information security and incident management;
operational resilience and third-party dependencies; and
the clarity and consistency of the evidence supplied.
The exact evidence requested must come from the prospective acquirer. The six areas below are preparation categories, not a reproduction of any named bank's confidential underwriting checklist.
Gap 1 — Unclear or outdated PCI DSS validation evidence
An Attestation of Compliance (AOC) is an official PCI Security Standards Council form used to attest the result of a PCI DSS assessment. It is not always a document “produced by a QSA.”
For an eligible self-assessment, the organisation completes the applicable Self-Assessment Questionnaire (SAQ) and associated AOC. Where a Report on Compliance (ROC) is required, the assessment and reporting route normally involves a Qualified Security Assessor (QSA), subject to the applicable payment-brand or acquirer programme.
PCI SSC sets the security standard, but payment brands and acquirers determine validation and reporting requirements. PCI SSC therefore tells merchants to contact their acquirer or payment brand to confirm what they must submit.
For example, Visa and Mastercard generally classify merchants processing more than one million and up to six million transactions annually as Level 2. Their published programmes ordinarily identify an annual SAQ for Level 2 merchants, but an acquirer or payment brand may impose different or additional validation requirements. The appropriate SAQ is determined by the payment environment and eligibility criteria; Level 2 does not automatically mean SAQ D.
Prepare this evidence
Confirmation from your acquirer or payment brand of the required validation route.
The applicable, completed SAQ and AOC, or ROC and associated AOC.
The assessment completion date and evidence that annual revalidation is being managed.
Applicable Approved Scanning Vendor results where required.
An accurate description of payment channels, service providers and PCI DSS scope.
Evidence supporting SAQ eligibility rather than selecting a shorter SAQ because it is convenient.
Ask yourself
If an acquirer requested your current PCI DSS validation package, could you provide the correct documents and explain why that validation route applies?
Gap 2 — Poorly understood fraud and dispute performance
Visa and Mastercard operate separate monitoring programmes, and those programmes and thresholds can change. Visa's evolved Visa Acquirer Monitoring Program (VAMP), introduced from April 2025, brought fraud and dispute monitoring together for card-not-present activity. Mastercard publishes separate compliance programmes, including its Excessive Chargeback Program and Excessive Fraud Merchant programme.
It is therefore inaccurate to present 0.5% as a universal warning threshold or 1% as the point at which every merchant enters monitoring. The applicable calculation, threshold and consequence depend on the scheme, programme, region, period and merchant or acquirer relationship. An acquirer may also apply contractual risk limits that are tighter than a scheme programme.
High or volatile dispute and fraud levels can still be significant during underwriting. The important point is to know your data, use the correct definitions and be able to explain what is driving the results.
Prepare this evidence
Monthly transaction, fraud, dispute and refund data using clearly defined measures.
The calculation method used for each ratio and the period to which it applies.
Scheme or acquirer notifications, if any.
Root-cause analysis for material increases.
Prevention measures such as authentication, fraud rules and customer communications.
Dispute-handling procedures, ownership and remediation outcomes.
Do not describe your performance as below “the threshold” until you have confirmed which scheme programme and contractual metric applies.
Ask yourself
Can your risk, finance and engineering teams explain the same fraud and dispute figures, including the denominator, reporting period and source system?
Gap 3 — Resilience claims without tested evidence
Using AWS does not by itself demonstrate operational resilience. Cloud services provide capabilities, but the organisation remains responsible for designing, configuring, testing and operating its workload appropriately.
Multi-Availability Zone deployment can improve availability within a region. It should not automatically be described as a complete disaster-recovery strategy. Recovery from data corruption, credential compromise, a destructive deployment, third-party failure or a regional disruption can require different controls and procedures.
Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are useful engineering measures, but they should reflect business impact and tested capability—not targets selected only for a questionnaire.
For firms within scope of the FCA's operational-resilience rules, the regulatory framework focuses on identifying important business services, setting impact tolerances, mapping supporting resources and carrying out scenario testing against severe but plausible disruption. Those rules do not apply identically to every fintech or merchant, but they illustrate why evidence matters more than a generic promise of high availability.
Prepare this evidence
A current map of payment-critical services, dependencies and responsible owners.
Business continuity and recovery procedures appropriate to the service.
RTO and RPO targets supported by business-impact analysis.
Backup, restoration and failover test results.
Scenarios covering relevant cloud, data, security, people and third-party failures.
Findings, remediation actions and lessons learned from exercises and incidents.
There is no universal acquirer rule requiring every applicant to conduct exactly one disaster-recovery test in each 12-month period. Testing frequency should reflect applicable regulation, contracts, risk and material change. Record why the chosen frequency is appropriate.
Ask yourself
What evidence demonstrates that the payment service can recover within its stated objectives under the scenarios that matter to your business?
Gap 4 — Financial-crime controls that do not match the business model
AML, customer due diligence and governance obligations depend on the legal entity's activities, regulatory status, jurisdictions and role in the payment chain. It is not accurate to say that every UK fintech must have the same AML programme or MLRO appointment letter.
Where the organisation is subject to the UK Money Laundering Regulations or relevant FCA rules, it must maintain proportionate, risk-based systems and controls. A regulated payment firm may need to demonstrate how it assesses customers, monitors relevant activity, escalates concerns, keeps records and assigns senior responsibility.
An ordinary merchant applying for card acceptance may face a different review from a payment facilitator onboarding sub-merchants or a regulated payments business providing services to customers. The acquirer will also conduct its own know-your-business and risk assessment of the applicant.
Using a third-party identity or verification provider can support the process, but technology does not make the underlying risk decision. The organisation should understand the provider's role, configure it for its risks, handle exceptions and retain ownership of decisions for which it is responsible.
Prepare this evidence where applicable
Business-wide and customer risk assessments.
Current AML and customer-due-diligence policies proportionate to the business.
Defined ownership, including a nominated officer or MLRO where legally required.
Customer or merchant onboarding and enhanced-due-diligence procedures.
Ongoing monitoring and escalation processes appropriate to the risk.
Training, quality assurance, management information and record keeping.
Oversight of outsourced providers and evidence of how their outputs are used.
Ask yourself
Can you connect each financial-crime control to a real risk, legal obligation, owner and item of operating evidence?
Gap 5 — Penetration testing that is missing, incomplete or misunderstood
PCI DSS v4.0.1 Requirement 11.4 covers regular internal and external penetration testing and the correction of exploitable vulnerabilities and security weaknesses. Where the relevant requirements apply, internal and external penetration tests are performed at least once every 12 months and after significant infrastructure or application changes. Segmentation controls also have specific testing requirements where segmentation is used to reduce scope.
The original claim that an internal test can never satisfy PCI DSS for Level 1 or Level 2 merchants was incorrect. PCI DSS permits qualified internal resources or qualified external third parties to perform relevant penetration testing, provided the tester has appropriate competence and organisational independence. The tester is not required to be a QSA or Approved Scanning Vendor.
An Approved Scanning Vendor designation applies to the PCI DSS external vulnerability-scanning programme. It should not be presented as a general PCI SSC approval for penetration-testing companies.
The useful evidence is not merely a report with no findings. A credible process establishes scope and methodology, records findings, remediates exploitable vulnerabilities and repeats testing to verify corrections.
Prepare this evidence where Requirement 11.4 applies
The documented penetration-testing methodology and scope.
Results from the latest applicable internal and external tests.
The tester's qualifications and evidence of organisational independence.
A remediation log with owners and target dates.
Retest evidence confirming that exploitable vulnerabilities were corrected.
Testing following applicable significant changes.
Segmentation-test evidence where segmentation is relied upon for PCI DSS scope reduction.
Ask yourself
Can you show not only that testing occurred, but that its scope was appropriate and its findings were resolved and retested?
Gap 6 — Sanctions controls based on assumptions rather than risk
UK financial sanctions apply according to UK law and jurisdiction. FCA-regulated firms are expected to maintain adequate systems and controls to mitigate sanctions risk, but neither the FCA nor OFSI sets a universal rule requiring every fintech to screen every transaction in real time or once per day.
The appropriate control design depends on the business model, customer and payment risks, products, geographies and applicable sanctions regimes. It may include screening at onboarding, when relevant data changes, when lists are updated, periodically, and at an appropriate point in a transaction or payout process. The firm should be able to justify its approach and prevent prohibited activity.
List selection must also reflect jurisdiction. Since 28 January 2026, the UK Sanctions List has been the only source for all UK sanctions designations; the former OFSI Consolidated List is no longer updated. EU and US lists may also be relevant where the organisation has exposure to those jurisdictions, but OFAC and EU lists are not automatically the governing sources for every UK transaction.
Manual processes are not automatically prohibited, and automation is not automatically effective. The control needs adequate data, matching logic, list updates, alert review, escalation, record keeping and governance. A poorly configured automated system can miss true matches or generate so many false positives that alerts are not investigated properly.
Prepare this evidence where applicable
A documented sanctions risk assessment and control framework.
The lists used and the legal or risk basis for using them.
The points and frequency at which customers, counterparties or transactions are screened.
Evidence that list updates are obtained and applied promptly.
Matching rules, alert-handling procedures and escalation routes.
Decisions, licences, reporting and audit records where relevant.
Testing, management information and oversight of screening providers.
Ask yourself
Can you explain why your screening design is appropriate for your exposure and demonstrate that alerts and potential matches are handled effectively?
Build an evidence pack—not a collection of confident statements
Strong due-diligence preparation does not mean predicting every question. It means knowing which claims you can support and identifying uncertainty before an external reviewer does.
A useful internal evidence pack might include:
A company, ownership and transaction-profile summary.
Confirmation of the required PCI DSS validation route and current evidence.
Fraud, dispute and refund metrics with definitions and trends.
Architecture, data-flow, security and third-party dependency diagrams.
Resilience objectives, procedures and test results.
Applicable AML, customer-due-diligence and sanctions documentation.
Penetration-test scope, findings, remediation and retest evidence.
A list of open issues that states the owner, risk and remediation date.
An open issue is not necessarily fatal. An unsupported claim is often harder to defend because it raises questions about the reliability of the rest of the submission.
Review your readiness before the acquirer conversation
The SyncYourCloud Acquiring Bank Readiness Report is a structured self-assessment covering 30 fields across five areas:
company and transaction profile;
PCI DSS compliance;
technical infrastructure;
regulatory and compliance processes; and
operational readiness.
It produces an indicative summary designed to help you organise your current information, identify areas requiring further review and prepare for discussions with your legal, compliance and technical advisers.
The assessment takes approximately 15 minutes.
Complete the Acquiring Bank Readiness Report →
The report is a self-assessment based on the information submitted. It does not determine PCI DSS or regulatory compliance, replace an acquirer, QSA or legal adviser, or guarantee approval by an acquiring bank.
Authoritative references
This article was reviewed against sources available on 24 August 2026. Scheme programmes and regulatory guidance can change, so confirm current requirements before relying on a specific threshold or submission route.
PCI Security Standards Council: PCI DSS v4.0.1 Document Library
Visa: Account Information Security programme and merchant levels
Mastercard: Site Data Protection programme and merchant levels
This article is general information, not legal, regulatory or PCI DSS advice. Requirements depend on the organisation, activity, jurisdiction, payment-brand programme, acquirer and contractual relationship.
