AML Compliance API for Fintechs: Complete Integration Guide (2026)

Anti-money laundering compliance is not optional for fintechs. Whether you are building a payment app, a neobank, a lending platform, or a crypto exchange, regulators expect you to have robust AML controls from day one. The challenge is that AML compliance is broad. It covers customer screening, transaction monitoring, PEP checks, sanctions list screening, and ongoing due diligence. Building all of this in-house would take months and cost a fortune.

The modern approach is to use APIs. This guide covers the four pillars of AML compliance, how to integrate each with APIs, and how to architect a compliance pipeline that satisfies regulators without slowing down your product.

The four pillars of AML compliance

AML compliance for fintechs can be broken down into four core pillars. Each addresses a different aspect of the money laundering risk, and regulators expect you to have controls for all four.

Pillar 1: Customer screening at onboarding

The first line of defense is screening every customer when they sign up. Before you open an account, process a transaction, or establish a business relationship, you must check whether the customer appears on any sanctions lists or is a politically exposed person.

This is where most fintechs start their compliance journey, and it is the most critical checkpoint. OFAC operates under a strict liability regime, meaning you can be fined even if you did not know the customer was sanctioned. Intent does not matter. If you process a transaction involving a sanctioned person, you are liable. Fines start at $330,000 per violation and can reach into the millions.

Customer screening should check against:

• OFAC SDN list (18,000+ entries, the primary U.S. sanctions list)
• UN Security Council consolidated list (international sanctions)
• EU Consolidated List (European Union sanctions)
• UK HM Treasury sanctions list (UK sanctions, post-Brexit separate from EU)
• PEP databases (900,000+ politically exposed persons globally)

Pillar 2: Transaction monitoring

Screening at onboarding catches known bad actors, but it does not catch customers who become sanctioned after they open an account, or customers who use your platform for suspicious activity. Transaction monitoring fills this gap.

Transaction monitoring involves analyzing patterns of financial activity to detect behavior that may indicate money laundering. Common red flags include:

• Structuring: Breaking large transactions into smaller amounts to avoid reporting thresholds (also called smurfing).
• Rapid movement: Funds deposited and immediately transferred out, especially to high-risk jurisdictions.
• Round-trip transactions: Money sent to an entity and then returned, potentially through a different path.
• Inconsistent activity: Transaction patterns that do not match the customer's stated business or income level.

Transaction monitoring is typically handled by dedicated platforms or built as custom rules engines. This is one area where Verifex does not currently compete directly. Our focus is on the screening pillar. For transaction monitoring, fintechs often use platforms like Unit21, Sardine, or build custom rule engines on top of their transaction data.

Pillar 3: PEP screening

Politically Exposed Persons require enhanced due diligence because their positions of power make them statistically more likely to be involved in corruption. PEP screening is a subset of customer screening, but it deserves its own pillar because the regulatory requirements and risk management approach are distinct.

When you identify a PEP, you do not automatically reject them. Instead, you apply enhanced due diligence: verify source of wealth, verify source of funds, obtain senior management approval, and implement ongoing monitoring. The key is that you must identify PEPs in the first place, which requires screening against comprehensive PEP databases.

Verifex screens against 900,000+ PEPs sourced from Wikidata, covering all 195 countries. PEP screening happens in the same API call as sanctions screening. You do not need a separate integration.

Pillar 4: Ongoing due diligence and re-screening

AML compliance is not a one-time check. Sanctions lists are updated multiple times per week. New PEPs are appointed daily. A customer who was clean at onboarding might be sanctioned six months later.

Ongoing due diligence requires periodic re-screening of your entire customer base against updated lists. The frequency depends on your risk appetite and regulatory requirements, but weekly or monthly re-screening is standard practice.

Verifex supports batch screening for exactly this use case. You can submit your entire customer list via the batch API and receive results for all customers in a single operation. This makes periodic re-screening operationally simple rather than a manual nightmare.

Integration architecture

Here is how a typical AML compliance pipeline looks for a fintech application:

                    AML Compliance Pipeline
                    ======================

  Customer Signup          Transaction              Weekly Cron
       |                       |                        |
       v                       v                        v
  +-----------+         +-------------+         +-------------+
  | Verifex   |         | Transaction |         | Verifex     |
  | Screen    |         | Monitoring  |         | Batch       |
  | API       |         | Engine      |         | Re-screen   |
  +-----------+         +-------------+         +-------------+
       |                       |                        |
       v                       v                        v
  +-----------+         +-------------+         +-------------+
  | Risk      |         | Alert       |         | Delta       |
  | Decision  |         | Queue       |         | Report      |
  +-----------+         +-------------+         +-------------+
       |                       |                        |
       v                       v                        v
  Approve /              Review /                New matches
  Reject /               Escalate /              flagged for
  EDD                    File SAR                review

The architecture has three integration points. First, real-time screening at customer signup via the Verifex API. Second, transaction monitoring through your own rules engine or a dedicated platform. Third, periodic batch re-screening via the Verifex batch API. Each produces outputs that feed into your compliance team's review queue.

Code example: Python integration

Here is a complete example of integrating Verifex screening into a Python backend. This covers onboarding screening with error handling and risk-based decision logic:

from verifex import Verifex

client = Verifex(api_key="YOUR_API_KEY")

def screen_customer(name: str, dob: str = None, nationality: str = None):
    """Screen a customer at onboarding."""
    result = client.screen(
        name=name,
        type="person",
        dob=dob,
        nationality=nationality,
    )

    if result.risk_level == "high":
        # Block account creation, flag for compliance review
        return {"action": "block", "matches": result.matches}
    elif result.risk_level == "medium":
        # Allow signup but require manual review
        return {"action": "review", "matches": result.matches}
    else:
        # No matches or low risk — approve
        return {"action": "approve", "matches": []}

# Screen at signup
decision = screen_customer(
    name="John Smith",
    dob="1985-03-15",
    nationality="US"
)

if decision["action"] == "block":
    print("Account blocked — sanctions match detected")
elif decision["action"] == "review":
    print("Account created — flagged for compliance review")
else:
    print("Account approved — no matches found")

Code example: Node.js integration

The same integration in Node.js using the Verifex SDK:

import Verifex from "verifex";

const client = new Verifex({ apiKey: "YOUR_API_KEY" });

async function screenCustomer(name, dob, nationality) {
  const result = await client.screen({
    name,
    type: "person",
    dob,
    nationality,
  });

  if (result.riskLevel === "high") {
    return { action: "block", matches: result.matches };
  } else if (result.riskLevel === "medium") {
    return { action: "review", matches: result.matches };
  }
  return { action: "approve", matches: [] };
}

// Screen during user registration
const decision = await screenCustomer(
  "John Smith",
  "1985-03-15",
  "US"
);

switch (decision.action) {
  case "block":
    console.log("Account blocked — sanctions match detected");
    break;
  case "review":
    console.log("Account created — flagged for compliance review");
    break;
  default:
    console.log("Account approved — no matches found");
}

Regulatory landscape in 2026

The regulatory environment for fintech AML compliance has tightened significantly. Here are the key regulations you need to be aware of:

• OFAC strict liability (US): You are liable for sanctions violations regardless of intent. No mens rea requirement. This is the most aggressive enforcement regime in the world for sanctions compliance.
• EBA/GL/2024/14 (EU): The European Banking Authority now requires fuzzy matching algorithms for sanctions and PEP screening. Exact name matching alone is no longer considered adequate. Compliance deadline is December 2026.
• FATF Recommendations 10-22: The Financial Action Task Force sets the global standard for AML compliance. Recommendations 12 and 22 specifically address PEP requirements. FATF mutual evaluations assess country compliance, and poor ratings can result in grey-listing.
• 6AMLD (EU): The 6th Anti-Money Laundering Directive expanded the list of predicate offenses for money laundering and introduced tougher penalties. It also clarified that compliance obligations extend to crypto asset service providers.
• MiCA (EU): The Markets in Crypto-Assets regulation brings crypto firms under the same AML framework as traditional financial institutions. If you operate a crypto exchange or custodial wallet in the EU, full AML compliance is now mandatory.
• FinCEN CDD Rule (US): The Customer Due Diligence rule requires financial institutions to identify and verify the identity of beneficial owners of legal entity customers. This means screening not just the company name but the individuals behind it.

Common mistakes fintechs make

After working with hundreds of fintech companies on their screening integration, we see the same mistakes repeatedly:

• Screening only at onboarding. Sanctions lists change weekly. If you only screen at signup, you will miss customers who get sanctioned after they join your platform. Batch re-screening is essential.
• Using exact match only. A customer named "Mohammad" will not match "Mohammed" with exact matching. Sanctions evasion often involves name variations that only fuzzy matching can catch. This is now a regulatory requirement under EBA/GL/2024/14.
• Ignoring PEPs. Many startups implement sanctions screening but skip PEP screening entirely. Regulators view this as a gap in your AML program. PEPs are not necessarily bad actors, but they require enhanced due diligence.
• No audit trail. Every screening decision needs a timestamp, the query submitted, the results returned, and the action taken. If a regulator asks you to prove that you screened customer X on date Y, you need to produce that record.
• Blocking all matches. Not every match is a true positive. A score of 0.65 on a common name like "Mohammed Ali" is probably a false positive. You need risk-based decision logic that considers match confidence, not a binary block/allow.

Batch re-screening for ongoing compliance

Ongoing compliance requires periodic re-screening of your entire customer base. Here is how to implement this with Verifex:

from verifex import Verifex

client = Verifex(api_key="YOUR_API_KEY")

# Weekly re-screening of all customers
customers = get_all_active_customers()  # Your database query

for customer in customers:
    result = client.screen(
        name=customer.name,
        type="person",
        dob=customer.dob,
        nationality=customer.nationality,
    )

    if result.risk_level in ("high", "medium"):
        # New match found — flag for compliance review
        create_alert(
            customer_id=customer.id,
            matches=result.matches,
            screened_at=result.timestamp,
        )

Why Verifex for the screening pillar

AML compliance has multiple pillars, and no single vendor covers all of them. Verifex focuses on doing the screening pillar exceptionally well:

• 984,000+ entities from 27 sanctions and PEP sources, synced daily
• 93.5% F1 score on standard screening benchmarks, balancing precision and recall
• Sub-100ms latency for real-time screening in onboarding flows
• Python and Node.js SDKs published on PyPI and npm
• Free tier with 100 screens/month for testing and early-stage products
• EBA/GL/2024/14 compliant with fuzzy matching built in by default

For transaction monitoring, you will need a separate solution. For screening, whether at onboarding, during transactions, or as part of periodic re-screening, Verifex gives you production-grade compliance at startup-friendly pricing.

Getting started

Building AML compliance into your fintech app does not need to be a six-month project. Start with the screening pillar, which is the most critical and the most straightforward to implement. Sign up for a free Verifex account, integrate the SDK into your onboarding flow, and you have covered the foundation of your AML program.

From there, add batch re-screening on a weekly cron job, implement risk-based decision logic for matches, and build your audit trail. The entire screening integration can be done in a day. The compliance program around it grows over time as your business scales.