Treasury, Payments & Fraud Prevention

Treasury and payments teams are the last control point before money leaves the organization. They process payments against vendor records they didn't create, using taxpayer data they didn't validate, on behalf of business relationships they didn't establish. When a vendor record is fraudulent — a ghost vendor created to divert payments, a legitimate vendor impersonated by a bad actor who changed the bank account, a vendor whose name doesn't match its EIN because the record was set up wrong — the payment runs anyway, because the control at the payment release point assumes the vendor record is clean. It isn't always. IRS TIN matching at the payment control layer confirms that the entity receiving the payment is the IRS-registered entity whose name and EIN are on the vendor record. A vendor record where the name and EIN don't match IRS records is either a data quality error or a fraud indicator. Either way, it's a payment that shouldn't release without review. TIN Comply gives treasury and payments teams the IRS TIN matching, OFAC sanctions screening, and vendor identity verification infrastructure to apply that check at the payment control point — and to do it at the volume and speed payment operations require.

The Payment Control Gap That TIN Matching Closes

Most payment approval workflows verify that an invoice exists, that it matches a purchase order, that the payment amount is within authorization limits, and that the approver has the appropriate authority. What standard AP controls typically don't verify is whether the vendor record the payment is releasing against represents a real, IRS-registered entity whose name and EIN actually belong together.

What standard payment controls verify vs. what IRS TIN matching adds:
Standard Payment Controls IRS TIN Matching Adds
Invoice matches purchase order Whether the vendor's name and EIN belong to the same IRS-registered entity
Payment amount within authorization threshold Whether the entity receiving payment actually exists in IRS records
Approver has appropriate authority Whether the vendor record reflects the real legal identity of the counterparty
Bank account on file for the vendor Whether a mismatched name/EIN is a data quality error or a fraud indicator
Vendor is in the approved vendor list Whether the vendor has been screened against OFAC and 250+ sanctions lists

A ghost vendor — a fictitious entity created in the AP system to divert payments — typically has a fabricated EIN that doesn't resolve against IRS records, or a real EIN paired with a name that doesn't match the IRS registration for that EIN. IRS TIN matching at the payment control layer catches both.


Vendor Fraud Patterns That TIN Matching Detects

Payment fraud schemes that target AP and treasury systems rely on the assumption that vendor identity isn't verified at the point of payment. The most common schemes have detectable signals in the name/TIN relationship that TIN Comply's IRS matching surfaces.

Vendor fraud patterns and TIN matching signals:
Fraud Pattern How It Works TIN Matching Signal
Ghost vendor creation Fraudulent employee creates fictitious vendor with fabricated EIN Invalid TIN or mismatch — fabricated EIN doesn't resolve against IRS records
Vendor impersonation Fraudster submits fake W-9 for a real vendor's name with a different EIN Mismatch — submitted name doesn't resolve against submitted EIN
Real EIN, wrong name Real EIN from a different business entity used for a fraudulent vendor Mismatch — EIN is registered to a different legal name
Shell company with real EIN Shell company registered with IRS using generic or obscure name; used as payment recipient Name resolves, but entity existence confirmed — EIN & Company Lookup surfaces registered name
Bank account change with identity confusion Legitimate vendor impersonated; bank account changed; name/EIN inconsistency introduced Mismatch on re-validation triggers review before payment releases

TIN Comply doesn't replace a full fraud prevention program — bank account verification, positive pay, dual authorization for high-value payments, and other controls remain essential. What TIN matching adds is the specific check on vendor legal identity that fraud prevention controls typically don't include: does this name and EIN belong together in IRS records?


OFAC Screening at the Payment Control Point

OFAC sanctions compliance requires that payments aren't made to sanctioned entities or individuals. In most organizations, OFAC screening happens at vendor onboarding — the vendor is screened when they're added to the vendor master, and the assumption is that the screening result from onboarding covers subsequent payments. Two problems with this:

First, OFAC lists are updated continuously. A vendor that was clean at onboarding may be designated after onboarding, and a point-in-time screening result doesn't catch new designations.

Second, if OFAC screening didn't happen at onboarding — which is more common than treasury teams realize, especially in vendor populations onboarded before a compliance program was formalized — the vendor has never been screened.

OFAC exposure scenarios that payment-point screening catches:
Scenario Why Onboarding Screening Alone Misses It
Vendor designated after original onboarding OFAC list updated post-onboarding; point-in-time screening result is stale
Vendor never screened at onboarding Legacy vendor in AP system predates formal OFAC screening program
Vendor acquired by sanctioned entity Entity structure changed after onboarding; beneficial ownership now sanctioned
New payment to infrequent vendor Vendor last paid years ago; no re-screening since original onboarding
High-value payment triggering enhanced review Payment size justifies real-time re-screen regardless of prior history

TIN Comply's OFAC and 250+ list screening runs automatically with every TIN matching call — so the payment-point validation confirms both vendor identity and current sanctions status in a single step.


High-Value Payment Validation Workflow

For treasury teams managing high-value ACH and wire payments — payments above defined thresholds that require enhanced controls — TIN Comply's API supports a pre-release validation step that confirms vendor identity and sanctions status before the payment is authorized for release.

Payment Control Stage TIN Comply Integration Point Action
New vendor creation API call at vendor master record creation TIN match + OFAC screening — mismatch blocks record creation
Vendor bank account change API call triggered by bank account update event Re-validation — name/EIN consistency confirmed after change
High-value payment pre-release API call in payment authorization workflow Real-time TIN match + OFAC screening before payment releases
Infrequent vendor reactivation API call when vendor inactive for defined period is reactivated Revalidation — stale record confirmed before payments resume
Bulk periodic re-screening Scheduled batch validation across full vendor master Portfolio-wide OFAC re-screen and TIN revalidation

Vendor Impersonation and Bank Account Change Fraud

Business Email Compromise (BEC) schemes targeting AP and treasury frequently involve convincing a vendor's AP contact that the vendor has changed their banking information. The fraudster, posing as the vendor, requests a bank account update — and subsequent payments go to the fraudster's account rather than the legitimate vendor.

A bank account change request is one of the highest-risk events in a payment workflow. When a bank account change is submitted, re-validating the vendor's name and TIN against IRS records confirms that the entity requesting the change is still the IRS-registered entity in the vendor master — not an impersonator who has substituted their own TIN information alongside the bank account change.

The recommended control for bank account change requests: require a new W-9 submission through TIN Comply's electronic portal as part of the bank account change approval workflow. The new W-9 triggers IRS TIN matching against the existing vendor record — if the name and TIN on the new W-9 don't match the confirmed identity on file, the bank account change is flagged for review before it's processed. A legitimate vendor updating their banking information will provide consistent taxpayer identification. A fraudster impersonating the vendor may not.

Duplicate Vendor and Fictitious Vendor Detection

Duplicate vendor records — the same entity appearing multiple times in the vendor master with different vendor IDs, slightly different names, or inconsistent TINs — create payment risk independent of fraud. Payments may be made against the wrong vendor record, spend data can't be consolidated, and compliance screening may have been completed on one record but not the other.

TIN Comply's bulk validation with TIN-keyed analysis identifies: records sharing the same confirmed EIN (potential duplicates), records where the same name appears with different EINs (potential data errors or impersonation), and records where the submitted EIN doesn't resolve against IRS records at all (potential ghost vendors or data entry errors). This analysis gives treasury and AP teams a risk-stratified view of the vendor master from an identity integrity standpoint.


How TIN Comply Supports Treasury and Payments Compliance

Capability Treasury / Payments Application
Real-time IRS TIN/Name matching Pre-payment vendor identity confirmation — single-record API call at payment authorization
OFAC & sanctions screening (250+ lists) Real-time sanctions clearance at payment release — not just at onboarding
EIN & Company Lookup Independently verify vendor legal entity name from IRS records — out-of-band identity confirmation
Bank account change re-validation W-9 re-submission and TIN re-matching triggered by bank account update event
Bulk file processing Full vendor master validation — TIN-keyed analysis for duplicate and ghost vendor detection
Periodic re-screening Scheduled OFAC re-screen across all active vendors — catches new designations
Electronic W-9 collection Enforced for bank account changes and vendor updates — prevents fraudulent document substitution
API integration Payment authorization systems, ERP AP workflows, treasury management systems
Per-vendor audit trail Every validation, screening, and re-validation retained — internal audit and fraud investigation ready

Specific Scenarios TIN Comply Handles for Treasury and Payments

The high-value payment where the vendor's name and EIN don't match. A $240,000 ACH payment is queued for a vendor. TIN Comply's pre-release validation returns a mismatch — the vendor's name in the system doesn't resolve against the EIN on file. Treasury holds the payment, contacts the vendor through an independently verified channel, and discovers the vendor record has a data entry error from the original onboarding. Corrected W-9 collected, revalidated, payment released to the correct entity.

The bank account change request from a vendor the AP team has worked with for years. A vendor submits a bank account change request by email. Standard AP policy is to require a new W-9 for bank account changes. The new W-9 is submitted through TIN Comply's portal. TIN matching returns a mismatch — the EIN on the new W-9 doesn't match the confirmed EIN on the original W-9. Treasury escalates; investigation reveals a BEC impersonation attempt. The original bank account is preserved; no payment misdirected.

The vendor master with legacy records that predate the OFAC screening program. A treasury team implements TIN Comply and runs bulk validation across their full vendor master. The exception report identifies 340 active vendors who have never been screened against OFAC because they were onboarded before the current compliance program existed. One returns a potential match against a FinCEN advisory list. Compliance reviews and resolves; the remaining 339 are cleared and documented. The vendor master now has a baseline OFAC screening record for every active vendor.

The quarterly re-screening that catches a new OFAC designation. A scheduled quarterly re-screen of the active vendor population identifies a supplier that received a new SDN designation since the last re-screen. The supplier is flagged before the next payment run; procurement is notified; alternative supplier engaged. The OFAC violation that would have occurred on the next payment cycle is avoided.


Best Practices for Treasury and Payments Fraud Prevention

What treasury and payments teams with strong vendor identity controls do consistently:
  • Validate vendor TIN and legal name at onboarding — before the vendor is activated for payment
  • Re-validate at bank account changes — require new W-9 through TIN Comply portal as change control
  • Run TIN matching and OFAC screening at high-value payment pre-release for payments above defined thresholds
  • Re-screen infrequent vendors before reactivating payment runs after extended inactivity
  • Run periodic bulk re-screening of full active vendor population — quarterly or semi-annually
  • Use EIN & Company Lookup to independently verify vendor legal entity name for high-risk payment events
  • Run TIN-keyed duplicate analysis on vendor master — identify ghost vendor risk and consolidate duplicates
  • Retain per-vendor validation and screening documentation — internal audit and fraud investigation ready
  • Integrate TIN matching into the bank account change approval workflow as a required control step
  • Combine TIN matching with positive pay, dual authorization, and bank account verification controls — not as a replacement

Frequently Asked Questions for Treasury and Payments Teams

How does TIN Comply integrate with payment authorization and ERP AP workflows?

TIN Comply provides a REST API that integrates with payment authorization systems, ERP AP workflows (SAP, Oracle, Workday, NetSuite), and treasury management systems. The API can be called at defined payment control points — vendor creation, bank account change, high-value payment pre-release — and returns validation results that drive workflow routing decisions. Contact TIN Comply's team for specific integration details.

How quickly does TIN Comply's API return results for pre-payment validation?

Real-time single-record validation typically returns results in under 2 seconds — designed for use within payment authorization workflows where response time affects operational throughput.

Does TIN Comply replace positive pay, dual authorization, or bank account verification controls?

No — TIN Comply's TIN matching and OFAC screening address vendor legal identity and sanctions status, which are distinct from and complementary to bank account verification, positive pay, and dual authorization controls. The strongest payment fraud prevention programs layer multiple controls: identity confirmation (TIN Comply), account verification (bank account validation services), payment authorization (dual approval), and transaction monitoring (positive pay). Each addresses a different fraud vector.

What's the value of EIN & Company Lookup specifically for treasury teams?

EIN & Company Lookup allows treasury teams to independently verify what legal entity name the IRS has registered for a specific EIN — without relying on what the vendor submitted on their W-9. For high-value payment events where independent verification is warranted, looking up the IRS-registered name for a vendor's EIN and comparing it to the name in the vendor master is an out-of-band identity confirmation that catches both data errors and impersonation attempts.

How does TIN Comply support fraud investigation documentation?

TIN Comply's per-vendor audit trail retains every validation result, screening result, and re-validation event with timestamps. When a fraud event triggers an internal investigation or external reporting requirement, the TIN Comply record provides a timeline of when the vendor's identity was validated, what results were returned, and what actions were taken — supporting the investigation narrative and the documentation of what controls were operating at the time of the fraud attempt.


Put Vendor Identity Verification at the Payment Control Point

TIN Comply gives treasury and payments teams the real-time IRS TIN matching, OFAC sanctions screening, and vendor identity verification infrastructure to add an authoritative identity check to the payment control layer — confirming that the entity receiving payment is the IRS-registered entity the vendor record claims, before money leaves the organization.

Real-time API-embedded TIN matching and OFAC screening at vendor creation, bank account changes, and high-value payment pre-release. EIN & Company Lookup for independent out-of-band identity verification. Bulk vendor master analysis for ghost vendor and duplicate detection. Periodic portfolio re-screening for OFAC updates. And per-vendor documentation retained for internal audit and fraud investigation.

  • Real-time IRS TIN/Name matching — vendor identity confirmed at payment control points
  • OFAC and 250+ list screening — current sanctions status at payment release, not just at onboarding
  • Bank account change re-validation — W-9 re-matching required for account update approval
  • EIN & Company Lookup — independent IRS-registered name verification for high-risk payments
  • Ghost vendor and duplicate detection — TIN-keyed bulk analysis of vendor master
  • Per-vendor audit trail — internal audit, fraud investigation, and OFAC compliance documentation

Start Free Trial Request a Demo