The first platform to integrate directly with the UK Fair Payment Code

Insights

Beneficial ownership at the speed of AP: why PSC data matters in your vendor master

Beneficial ownership data lives in legal and compliance. Vendor master records live in finance. The gap between them is where fraud and sanctions risk hide. Here is why live PSC verification matters at AP velocity, what the integration pattern looks like, and why a network layer is the only viable way to keep the data current at scale.

Beneficial ownership at the speed of AP: why PSC data matters in your vendor master

Table of contents

Beneficial ownership data exists for a reason. Regulators introduced the PSC register and equivalents across jurisdictions to make hidden control structures visible. The intent was to support sanctions enforcement, anti-money laundering controls and counterparty due diligence. The implementation has succeeded as a disclosure regime. It has not succeeded as an operational input, particularly inside accounts payable. The gap between the regulatory data and the operational system is where fraud and sanctions risk now live.

Where PSC data sits in most firms

In a typical mid-market UK firm, beneficial ownership data lives in three places, none of which are accounts payable.

Legal, where it is captured during commercial contracting. The compliance team checks the supplier's PSC register entry at onboarding and files the result. This is part of the broader pattern that supplier onboarding is broken: data is captured cleanly, then frozen.

Compliance, in regulated firms, where it sits inside the KYC and AML evidence pack.

The supplier file, in some cases, where a PDF of the register entry is attached to the master record and never updated.

What none of these locations do is feed verification into the payment trigger. The PSC data is captured, filed, and then becomes inert.

The cases that hinge on UBO drift

The fraud and sanctions cases that fail in AP almost always involve a divergence between the beneficial ownership at onboarding and the beneficial ownership at the moment of payment.

Sanctions case. A supplier is acquired by a parent that is later added to a sanctions list. The PSC register reflects the change. The vendor master does not. Payments continue to flow to the acquired entity, which now sits inside a sanctioned group. The firm carries the regulatory exposure.

Fraud case. The supplier's controlling entity is changed without the firm's knowledge. The new controller redirects banking. The bank-detail change request looks routine because the request comes from a senior contact at the supplier. The verification fails because the firm is checking the supplier's identity, not the controller's. The wider fraud thesis sits in why AP fraud will explode in the AI era.

Tax case. The supplier's beneficial ownership shifts to a jurisdiction that triggers different withholding or VAT obligations. The vendor master does not reflect the change. The firm under-withholds and acquires a tax liability.

Each case is downstream of the same root: the PSC data is captured at onboarding and never updated against the live register.

What live PSC verification at AP velocity looks like

The goal is not to re-run KYC on every invoice. The goal is to refresh the PSC view on a cadence that matches the operational risk.

For the top fifty suppliers by spend, weekly. The cost of missing a change is high enough to justify the cadence.

For the next two hundred, monthly. The risk is lower but still material.

For the long tail, quarterly, with event-driven refresh on any bank-detail change or material invoice change.

Each refresh produces a delta. Where the delta is material, the supplier is flagged. The flag does not block payment by default. It routes the next invoice through a structured review. This is part of the operational case for treating supplier verification and payment behaviour as one discipline.

The integration pattern

Three components have to connect.

The vendor master, holding the supplier's current record.

The PSC register, or equivalent jurisdictional source, holding the regulatory view.

The payment trigger, where the invoice is processed and the next outflow is authorised.

The standard pattern is to schedule PSC refresh into the supplier record on the cadences above, and to embed a check on the payment trigger that confirms the supplier record is current within the refresh window. Where it is not, the payment is held pending refresh.

Why a network layer matters here

Running this internally is technically feasible. Running it on every supplier across every buyer in the country is not.

A supplier identity graph holds the supplier's PSC record once, refreshed continuously, and serves it to every buyer of that supplier. The cost per buyer falls toward zero. The cost per supplier falls because the supplier maintains a single canonical record rather than answering the same question for every buyer.

The structural argument for a network is the same here as it is for behavioural data. A single buyer cannot economically refresh PSC data on every supplier at the cadence the risk requires. A network can, because the cost of the refresh is amortised across all buyers of the supplier.

Regulatory direction

The direction of travel on beneficial ownership across UK, EU and US frameworks is toward live, structured, machine-readable disclosure. The PSC register itself is moving in that direction. Firms whose AP processes treat PSC as a static onboarding artefact will be increasingly out of step with the regulatory expectation that the data is current.

FAQs

Is the PSC register accurate enough to use for live verification?
Does live PSC refresh slow down AP processing?
What jurisdictions are most exposed to UBO drift in supplier records?