Onboarding Controls: Secure Vendor Onboarding

The Onboarding Moment Is a Control Moment

Vendor onboarding is the point at which a new payment relationship is established — and it is one of the highest-risk moments in the entire accounts payable lifecycle. It is the moment when vendor identity is either verified or assumed, when banking information is either authenticated or taken on faith, and when the controls either hold or fail. What happens at onboarding sets the risk profile for every payment that follows.

Despite this, many organizations continue to treat vendor onboarding as a clerical intake process rather than a control function. The practical consequences are significant: fraudulent vendors are approved, legitimate vendor records are corrupted with criminal banking data and the organization has no systematic way to detect the problem until a payment has already been misdirected.

A secure vendor onboarding program treats the intake of every new vendor — and every change to an existing vendor's record — as a control event requiring structured verification, documented authorization, and a clear audit trail.

How Poor Onboarding Practices Create Fraud Exposure

The most common and costly onboarding failures share a common characteristic: they rely on informal, unverified channels to collect and process sensitive vendor data.

Email-based onboarding is the single most dangerous practice still in widespread use. When an AP team requests or accepts vendor banking information by email, they have no way to verify that the sender is who they claim to be, that the account information is legitimate or that the email itself has not been intercepted or spoofed. Business Email Compromise (BEC) and Vendor Email Compromise (VEC) attacks are specifically designed to exploit this vulnerability. Criminals compromise a vendor's email account — or spoof it convincingly — and submit fraudulent banking details that redirect payments to accounts they control. The AP team, following its standard process, processes the request in good faith. The fraud is often not detected until the legitimate vendor reports a missing payment, sometimes weeks later.

Other poor practices that expand fraud exposure include:

• Accepting vendor forms via fax, which provides no chain of custody and cannot be authenticated.
• Permitting verbal banking updates by phone without a call-back verification protocol.
• Allowing a single AP employee to both collect and enter vendor data without independent review.
• Failing to require any documentation beyond what the vendor self-reports.
• Having no systematic process for distinguishing a new vendor submission from a change request on an existing vendor record — a distinction that matters because change requests targeting existing, active vendors are among the most common vectors for payment fraud.

Each of these practices shares the same underlying flaw: they place the organization's trust in the channel rather than in verified identity.

The Secure Onboarding Framework: Best Practices

A defensible vendor onboarding program is built on four interlocking principles:

• structured intake,
• authenticated identity,
• verified banking data, and
• documented authorization.

The following controls operationalize each principle.

Encrypted Vendor Onboarding Portal

The foundation of a secure onboarding program is a dedicated, encrypted portal through which all vendors submit their information directly. Rather than relying on email or paper forms that pass through multiple hands, a vendor portal creates a controlled, auditable environment in which the vendor enters data themselves, the submission is time-stamped and logged, and the organization receives the data without it transiting an insecure channel.

Effective vendor portals require vendors to authenticate before submitting data — typically through a unique invitation link tied to a specific onboarding request, combined with multi-factor verification. This eliminates the impersonation risk inherent in email-based intake. The portal also creates an immutable record of who submitted what data and when, which is essential both for internal audit and for fraud investigation.

Organizations that have not yet implemented a dedicated portal should treat email and paper-based intake as a temporary, high-risk interim measure — not an acceptable long-term practice.

Identity Verification at the Point of Onboarding

Collecting a vendor's W-9 or W-8 is a tax compliance requirement, not an identity verification control. A vendor onboarding program that stops at the W-9 has established who a vendor claims to be, not who they are.

Robust identity verification includes confirming that the business entity exists as a legal entity in good standing, that the principals or signatories are who they represent themselves to be, and that the business address and contact information are consistent across independent sources. For higher-risk or higher-value vendor relationships, enhanced due diligence — including verification against Secretary of State business registries and independent contact directory lookups — is appropriate.

The depth of identity verification should be calibrated to vendor risk tier. A sole proprietor providing occasional services carries a different risk profile than a direct-spend supplier with a six-figure annual contract value, and the onboarding controls should reflect that distinction.

Bank Account Verification

Vendor banking information is the most sensitive data element in the onboarding record and the most frequent target of fraud. Banking data must never be accepted on a self-reported basis alone.

Best practice requires independent verification of bank account ownership before any payment is issued. This means confirming, through a source other than the vendor's own submission, that the account number and routing number provided actually belong to the business entity being onboarded. Modern bank account verification services can perform this check in real time, providing confirmation that the account exists, is active, and is held in the name of the entity claimed.

NACHA's account validation rule, which took effect for large originators in March 2026, now requires a commercially reasonable account verification method before initiating certain ACH credits — making this a compliance obligation, not merely a best practice, for organizations that meet the threshold.

For organizations not yet using automated verification services, a minimum acceptable practice is a pre-note or micro-deposit protocol, in which a small test transaction is sent and the vendor confirms receipt before live payment files are processed. This is slower and less secure than real-time validation, but it provides a baseline confirmation that the account is reachable before funds are committed.

Segregation of Duties in the Onboarding Workflow

No single individual should have the ability to create a new vendor record and authorize the first payment to that vendor. This segregation is a foundational internal control, and its absence is one of the most commonly cited conditions in AP fraud cases.

A properly segregated onboarding workflow separates the functions of data collection, data entry, data review, and payment approval among different individuals or roles. In smaller organizations where full segregation is operationally difficult, compensating controls — such as mandatory supervisory review of all new vendor approvals and system-enforced holds on first payments — provide an alternative layer of protection.

Documented Authorization and Approval Chain

Every new vendor activation and every change to an existing vendor's banking record should require documented authorization from a defined approver — not just a process step, but a named individual taking accountability for the approval. This documentation should be retained in the vendor file and accessible for audit.

The approval chain should be risk-tiered: routine low-value vendors may require single-level approval, while strategic or high-value suppliers should require sign-off from a finance manager or controller. Banking change requests on existing vendors — which carry elevated fraud risk because they target relationships that already have payment history — warrant the same level of scrutiny as new vendor activations, and in many programs, a higher level.

Sanctions and Debarment Screening at Onboarding

No vendor should be activated in the vendor master without a screening check against applicable sanctions and debarment lists. At minimum, this includes the OFAC Specially Designated Nationals (SDN) list, the GSA System for Award Management (SAM.gov) exclusions, and — for healthcare organizations and government contractors — the HHS OIG List of Excluded Individuals and Entities (LEIE).

Sanctions screening is not a one-time onboarding check; it must be performed on a continuous or periodic basis throughout the vendor relationship. But onboarding is the mandatory starting point. Activating a vendor without screening is an unacceptable compliance gap regardless of the organization's size or the perceived risk level of the vendor relationship.

New Vendor Holds and First-Payment Controls

A practical and underutilized control is the mandatory new vendor hold: a system-enforced waiting period between vendor activation and first payment, during which a supervisor or independent reviewer confirms the record before any funds are released. This hold provides a final review opportunity that catches data entry errors, incomplete verifications, and fraudulent records that may have passed through earlier control points.

First payments to new vendors — particularly those involving wire transfers or large ACH credits — warrant heightened scrutiny regardless of the hold period. Payment method risk should be factored into first-payment review thresholds.

After Onboarding: Controls for Vendor Record Changes

A vendor onboarding framework that does not address changes to existing vendor records is incomplete. The vendor master is not a static dataset; it is continuously updated as vendors change banking institutions, addresses, and contact personnel. Each update is a potential fraud vector.

Banking information changes are the highest-risk category of vendor record updates. They should require the same verification rigor as an initial banking data submission: independent verification of the new account, documented authorization from an approver who did not initiate the change, and in many programs, direct confirmation with the vendor via a pre-established, out-of-band contact method — not by replying to the email that initiated the change request.

The Audit Trail Imperative

A secure onboarding program generates and retains a complete audit trail: who submitted vendor data, through what channel, when it was received, who reviewed and approved it, what verifications were performed and by what method, and when the vendor was activated. This record is the organization's primary defense in the event of fraud, audit or regulatory inquiry.

Organizations that cannot reconstruct the onboarding history for any given vendor — who approved it, what was verified, and when — have a documentation gap that is itself a control deficiency, regardless of whether fraud has occurred.

From Intake Form to Control Framework

The difference between a vulnerable onboarding process and a defensible one is not complexity — it is intentionality. Secure vendor onboarding does not require elaborate technology, though purpose-built tools make it significantly more efficient and auditable. It requires treating the onboarding event as what it actually is: the moment at which a new payment obligation is created and the organization's control environment either validates or admits a new counterparty.

Organizations that rely on email, paper forms, and informal approval processes are not simply behind the curve on best practices. They are operating with a known, exploitable gap at one of the highest-risk points in their payment cycle. Closing that gap — through structured intake, authenticated identity, verified banking data, and documented authorization — is both a control imperative and, increasingly, a compliance requirement.