Boost AI Fraud Model Performance with 3rd Party Data

In the high-stakes world of fraud detection, every data point counts.

To reduce losses due to financial fraud, which are estimated at a staggering $500B per year, AI-driven fraud models need to tap into an intricate web of signals — from device fingerprints and behavioral biometrics to financial transaction histories and identity verification scores.

However, orchestrating the collection of these critical data points and using them for AI-driven detection at scale presents significant engineering challenges. The complexity of retrieving and post-processing fast-changing data from multiple APIs, managing connection pools, generating training data, and ensuring high inference throughput while maintaining low latency — all while trying to maintain clean feature engineering code — can overwhelm even experienced AI teams.

That’s why we’re excited to share Tecton’s API Resources, a powerful new capability that simplifies using data from fast-serving endpoints for feature calculations, letting modelers focus on building better models instead of plumbing data pipelines.

In this post, we’ll describe 4 common financial fraud detection types we’ve observed in the industry, share key 3rd party APIs that enhance fraud model performance, outline how Tecton’s API Resources streamline their integration, and share patterns for building powerful features with API-retrieved data.

Financial Fraud Detection Patterns & APIs

Financial fraud manifests in many patterns, each detectable through AI-driven approaches. We’ll discuss four prevalent types of financial fraud and explore how API-based features can boost detection accuracy.

First-Party Transaction Fraud

First-party transaction fraud occurs when legitimate customers intentionally abuse payment systems by making purchases with no intention to pay, often by exploiting credit lines, chargebacks, or refund policies while maintaining an appearance of normal consumer behavior.

Unlike third-party fraud, these attacks are particularly challenging to detect because they originate from genuine customer accounts with established histories, requiring sophisticated pattern analysis across payment behaviors, purchase velocity, and account lifecycle signals.

APIs such as Plaid Signal (which is built using Tecton), Sardine, and Experian CrossCore provide extremely valuable signals for building features for detecting transaction fraud. Example: Plaid Signal can provide a powerful feature for ACH transaction risk calculated using over 1,000 risk factors in under one second.

Financial Identity Fraud

Another common fraud pattern, financial identity fraud involves unauthorized financial activity where attackers manipulate payment systems using stolen cards, fake accounts, or compromised merchant credentials to execute illegitimate transactions.

APIs from companies such as Signifyd (a Tecton customer), BioCatch, Onfido, and Sift provide important signals for detecting financial identity fraud. Example: Signifyd’s API can help generate a feature that assesses the risk of account takeovers by analyzing user login patterns, device information, and behavioral biometrics — boosting identity fraud detection model performance.

Anti-Money Laundering (AML)

Anti-money laundering involves detecting attempts to disguise illegally obtained funds as legitimate by identifying complex patterns of financial transactions designed to obscure the origin of money, typically through a combination of layering, structuring, and integration techniques across multiple accounts and institutions.

Detection requires analyzing vast transaction networks, beneficial ownership structures, and customer behaviors to identify suspicious patterns like rapid fund movement, shell company operations, and unusual cross-border flows. APIs such as Seon, Unit21, ComplyAdvantage Sanctions Screening, provide valuable data for AML. Example: By integrating Seon’s API, one can create a feature that flags individuals identified as Politically Exposed Persons, helping decrease the risk level and comply with AML regulations.

Merchant Fraud

Merchant fraud occurs when bad actors exploit payment processing systems by establishing seemingly legitimate business accounts to process fraudulent transactions, often involving complex networks of shell companies, transaction laundering schemes, and unauthorized merchant aggregation.

Merchant Fraud detection needs analyses of patterns across merchant onboarding data, transaction flows, business registry information, and ultimate beneficial ownership (UBO) structures, as fraudulent merchants typically exhibit telltale signs in their processing patterns, industry code mismatches, and corporate structure anomalies that differentiate them from legitimate business operations. APIs such as Middesk, Dun & Bradstreet, Fourthline provide crucial signals for detection by verifying business legitimacy. Example: By integrating Middesk’s API, businesses can create a feature that assesses the risk level of merchants based on their KYB due diligence data.

API Resources

Tecton’s API Resources make it seamless to create the features mentioned above.

At a high-level, the steps for using an API Resource are:

1. Define a resource_provider which instantiates a client, that’s setup once and reused across feature invocations
2. Use the resource in a Realtime Feature View or Batch Feature View to invoke the API and post-process the results for feature calculation.

The below example shows the sample code for a simple realtime feature: is_transaction_amt_higher_than_balances which leverages the Plaid API to fetch current account balances for a user and compare them against a transaction amount.

@resource_provider(
    secrets={
        "plaid_client_id": Secret(scope="plaid", key="client_id"),
        "plaid_secret": Secret(scope="plaid", key="secret"),
    },
)
def plaid_client(context):
    import plaid
    from plaid.api import plaid_api

    configuration = plaid.Configuration(
			host=plaid.Environment.Sandbox,
		    	api_key={
		        'clientId': context.secrets["plaid_client_id"],
		        'secret': context.secrets["plaid_secret"],
		    	}
			)
    api_client = plaid.ApiClient(configuration)
    client = plaid_api.PlaidApi(api_client)
    return client
		
realtime_request = RequestSource(schema=[
		Field("access_token", String)
		Field("transaction_amount", Int64)
])

@realtime_feature_view(
    sources=[realtime_request],
    mode="python",
    features=[Attribute("is_transaction_amt_higher_than_balances", Bool)],
    resource_providers={"plaid_client": plaid_client},
)
def transaction_amt_higher_than_balances(input_request, context):
    from plaid.model.accounts_balance_get_request import AccountsBalanceGetRequest
    
    client = context.resources["plaid_client"]
    request = AccountsBalanceGetRequest(access_token=realtime_request["access_token"])
    response = client.accounts_balance_get(request)
    accounts = response['accounts']
		
    transaction_amt = realtime_request["transaction_amount"]
    total_balance = sum(account['balances']['available'] or 0 for account in accounts)
		
    return {"is_transaction_amt_higher_than_balances": transaction_amt >= total_balance}

Patterns of Using API Resources

There are some common patterns for feature creation using API Resources:

1. Post-processing API Retrieved data: oftentimes, data retrieved from third party endpoints needs to be post-processed for feature calculation. The is_transaction_amt_higher_than_balances feature shown above which post-processes the data returned by Plaid is one such example.
2. Making conditional calls based on batch, stream, or realtime data: API calls can be intelligently triggered based on specific conditions in your input data. For example, only calling Sardine’s Risk API when a user’s risk Batch Feature View value is above a certain threshold.
3. Querying an operational database: API Resources enable maintaining a fast, persistent connection to your production database, allowing you to seamlessly incorporate rapidly changing data such as a user’s current account balance or recent transaction history stored in a database such as PostgreSQL into your feature computations.

Conclusion

Building effective fraud detection models needs integration of diverse data, with specialized 3rd party APIs providing crucial signals across the fraud spectrum: from identity verification and device fingerprinting to business registry checks and transaction risk scoring. Yet the engineering complexity of managing these integrations often holds teams back from utilizing their full potential.

Tecton’s API Resources simplify this complexity. With Tecton, modelers can now focus on crafting sophisticated features from API-retrieved signals, maintain consistency between training and inference, and deploy high-performance feature pipelines — all through clean, shareable, production-ready code. For teams fighting financial fraud at scale, API Resources eliminates the infrastructure burden, enabling them to channel their energy into what matters most: building more accurate fraud detection models that protect their business and customers.