CDD and AML Compliance: Using Entity Verification APIs for Due Diligence

For compliance officers, fintech developers, and financial institutions operating in the United States, AML CDD business entity verification has never been more critical — or more complex. Regulators are tightening expectations around Customer Due Diligence (CDD) and Anti-Money Laundering (AML) programs, and manual verification workflows simply cannot keep pace with modern business volumes. This guide explains the regulatory landscape, the verification data you actually need, and how to automate entity lookups using the OpenSOSData API to build a defensible, scalable compliance program.

Why Entity Verification Is Central to AML and CDD

When a business opens an account, applies for credit, or initiates a transaction, your compliance team must answer a foundational question: Is this a real, legitimately registered business entity? The answer touches every layer of your AML program — from initial onboarding through ongoing monitoring.

Shell companies, fictitious entities, and lapsed corporations are among the most common vehicles used in money laundering schemes. The FATF (Financial Action Task Force) and U.S. regulators alike identify legal entity transparency as a primary control against financial crime. Without authoritative data from official Secretary of State records, any due diligence you perform is built on an uncertain foundation.

The US Regulatory Framework You Must Know

FinCEN's CDD Rule and Beneficial Ownership

FinCEN's CDD Rule (31 CFR Part 1010) requires covered financial institutions to identify and verify the identity of beneficial owners — individuals who own 25% or more of a legal entity customer — as well as a single individual with significant control. The 2024 Corporate Transparency Act (CTA) and its Beneficial Ownership Information (BOI) reporting requirements extended these obligations, mandating that most U.S. companies report ownership data directly to FinCEN.

For compliance teams, this means that verifying a beneficial owner's claimed business entity is now a regulatory imperative, not optional diligence. If a customer claims to represent "Acme Holdings LLC registered in Delaware," you need to confirm that entity actually exists and is in good standing before you accept their BOI declaration at face value.

Bank Secrecy Act (BSA) Obligations

Under the BSA, financial institutions must maintain AML programs with four core pillars: internal controls, independent testing, a designated compliance officer, and ongoing training. A fifth pillar — CDD — was formally codified in 2016. Entity verification feeds directly into your risk-based customer risk rating, which determines transaction monitoring thresholds, SAR filing decisions, and enhanced due diligence (EDD) triggers.

State-Level Business Registration as Ground Truth

In the U.S., business entities are registered at the state level with each state's Secretary of State (SOS) office. These public records are the authoritative source for entity name, entity type, status, registration date, registered agent, and principal address. Accessing this data programmatically — rather than relying on self-reported information — is the difference between verified compliance and checkbox compliance.

What a Secretary of State Lookup Returns (and Why It Matters)

A Secretary of State record typically provides:

• Entity Name — the official registered name, which may differ from a trade name or DBA
• Entity Type — LLC, Corporation, LP, etc., which affects governance and liability exposure
• Entity ID — the unique state-assigned identifier useful for cross-referencing
• Status — Active, Dissolved, Revoked, or similar — critical for determining if a business is currently authorized to operate
• Formation Date — helps assess business age, a risk factor in many scoring models
• Registered Agent and Address — required by law; a missing or suspect agent can indicate a shell entity

Each of these data points maps to a specific CDD control. For example, a "Revoked" status means the entity has lost its legal standing — a significant red flag if that entity is trying to open a bank account or process payments.

Automating Entity Verification with the OpenSOSData API

OpenSOSData provides a REST API covering all 50 U.S. states plus Washington D.C., Puerto Rico, and the U.S. Virgin Islands — over 34 million business entities indexed from official Secretary of State sources. Pricing is straightforward: live lookups cost $0.10 each (as low as $0.0314 with volume), and cached lookups cost $0.01 each (as low as $0.00314 with volume), with pay-as-you-go billing. See the full API documentation for endpoint details.

Python Code Example: Verifying a Business Entity

import requests
import json

# Your OpenSOSData API key — store this in an environment variable, never hardcode in production
API_KEY = "your_api_key_here"
API_URL = "https://api.opensosdata.com/v1/lookup"

def verify_business_entity(entity_name: str, state: str, live: bool = True) -> dict:
    """
    Query the OpenSOSData API to verify a business entity via Secretary of State records.

    Args:
        entity_name: The legal business name to look up (e.g., "Acme Holdings LLC")
        state:       Two-letter US state code (e.g., "DE" for Delaware)
        live:        If True, fetches a real-time live record; if False, uses cached data

    Returns:
        Parsed JSON response with entity details or error information
    """

    # Use cache_preference to control data freshness:
    # "live_only"    = always fetch from Secretary of State (most current, $0.10/lookup)
    # "cache_first"  = use cached if available, otherwise live
    # "cache_only"   = only return cached data ($0.01/lookup)
    cache_pref = "live_only" if live else "cache_first"

    headers = {
        "x-api-key": API_KEY,
        "Content-Type": "application/json"
    }

    payload = {
        "entity_name": entity_name,
        "state": state,
        "cache_preference": cache_pref
    }

    response = requests.post(API_URL, headers=headers, json=payload, timeout=30)
    response.raise_for_status()
    return response.json()

def assess_entity_risk(result: dict) -> str:
    """
    Basic CDD risk assessment based on Secretary of State data.
    Extend this logic with your institution's full risk scoring model.
    """
    status = result.get("status", "").lower()

    if status == "active":
        return "LOW_RISK — Entity is active and in good standing"
    elif status in ("dissolved", "revoked", "cancelled"):
        return f"HIGH_RISK — Entity status is '{status}'; do not onboard without EDD"
    else:
        return f"REVIEW — Entity status '{status}' requires manual compliance review"

# --- Example usage in a CDD onboarding workflow ---
if __name__ == "__main__":
    # Customer claims to represent this entity during account opening
    customer_entity = "Acme Holdings LLC"
    customer_state  = "DE"  # Delaware

    print(f"Running AML CDD entity verification for: {customer_entity} ({customer_state})")

    entity_data = verify_business_entity(customer_entity, customer_state, live=True)

    print("\n--- Secretary of State Record ---")
    print(json.dumps(entity_data, indent=2))

    risk_verdict = assess_entity_risk(entity_data)
    print(f"\n--- Compliance Assessment ---\n{risk_verdict}")

This pattern integrates cleanly into onboarding APIs, loan origination systems, or payment processing pipelines. For high-volume use cases, switch cache_preference to cache_first to reduce cost without sacrificing data quality for lower-risk lookups. You can sign up and get your API key here.

Live vs. Cached Lookups: Choosing the Right Option for Your Program

A balanced approach for most compliance programs: use live lookups at onboarding and EDD trigger points, and cached lookups for your periodic re-screening batch jobs. This optimizes both regulatory defensibility and operational cost.

Building a Defensible AML CDD Workflow

Integrating Secretary of State verification into your CDD program involves more than a single API call. Here is a recommended workflow structure:

1. Collect entity information at onboarding: legal name, state of formation, EIN, and beneficial owner details.
2. Run a live SOS lookup immediately via the OpenSOSData API. Confirm the entity exists, is active, and that the registered agent and formation date match customer-provided data.
3. Score the entity based on status, entity age, jurisdiction, and any mismatches between self-reported and SOS data.
4. Apply risk-tiered CDD measures: standard CDD for active, low-risk entities; EDD for high-risk jurisdictions, newly formed entities, or status mismatches.
5. Document your verification: store the API response with timestamp as part of your BSA recordkeeping. FinCEN examiners expect evidence that verification occurred.
6. Schedule periodic re-verification using cached lookups (monthly or quarterly) to catch status changes — dissolution, revocation, or agent changes.

This structured approach satisfies the FinCEN CDD Rule's requirements for both identity verification and ongoing monitoring, and creates an auditable trail for BSA examinations.

Frequently Asked Questions

Conclusion

Effective AML CDD business entity verification is no longer a manual, spot-check process — it is an automated, auditable, and risk-tiered control that regulators expect to see built into your onboarding and monitoring infrastructure. By combining FinCEN's CDD Rule requirements with real-time Secretary of State data from the OpenSOSData API, compliance teams can verify entities at scale, reduce false negatives, and maintain the documentation that BSA examinations demand. Start building a more defensible due diligence program today by exploring the full API documentation or signing up for a free account.