UK Sort Code and Account Number

Detects the paired UK domestic bank sort code (6 digits, written XX-XX-XX, XX XX XX, or XXXXXX) and account number (8 digits) as they normally appear together in UK bank-detail blocks (invoices, remittance advice, payroll/BACS instructions). Both digit groups must be directly attached to their own label ("sort code" / "account number" or "a/c no") in either order — bare unlabelled 6- or 8-digit sequences are never matched, because unlabelled digit sequences of this length collide heavily with dates, phone extensions, invoice numbers, and other structured identifiers.

Type: regex
Engine: universal
Confidence: medium
Confidence justification: Medium confidence: both digit groups are structurally anchored to their own label in either order, which materially reduces collision with unrelated digit sequences compared to a bare-digits pattern, but there is no checksum validator to confirm the sort code / account number combination is actually payable (UK modulus checking requires per-bank weight tables that are not expressible as a single Purview function). Evidence tiers exist for reliable production use; there is deliberately no bare/unlabelled 65 tier.
Jurisdictions: uk
Regulations: UK GDPR, Payment Services Regulations 2017
Frameworks: ISO 27001, ISO 27701, PCI-DSS, SOC 2
Data categories: financial, pii
Scope: narrow
Risk rating: 9
Platform compatibility: Purview: Compatible, GCP DLP: Compatible, Macie: Compatible, Zscaler: Compatible, Palo Alto: Degraded, Netskope: Unsupported

Pattern

(?i)(?:\bsort\s+code[\s:.-]{0,10}\d{2}[-\s]?\d{2}[-\s]?\d{2}\b[\s\S]{0,60}?\b(?:account(?:\s+(?:number|no\.?))?|a\/c(?:\s+(?:no\.?|number))?)[\s:.-]{0,10}\d{8}\b|\b(?:account(?:\s+(?:number|no\.?))?|a\/c(?:\s+(?:no\.?|number))?)[\s:.-]{0,10}\d{8}\b[\s\S]{0,60}?\bsort\s+code[\s:.-]{0,10}\d{2}[-\s]?\d{2}[-\s]?\d{2}\b)

Corroborative evidence keywords

BACS, CHAPS, Faster Payments, beneficiary, payee, remittance advice, bank transfer, sort code, account number, data record, database record, record set, data extract, data export, database table, spreadsheet, data registry, registry entry, master data, bulk export (+1 more)

Proximity: 300 characters

Should match

Sort Code: 12-34-56 Account Number: 12345678 — Hyphenated sort code followed by labelled account number
sort code 123456 account no 87654321 — Compact unhyphenated digits with abbreviated account label, sort code first
Account Number: 87654321, Sort Code: 65-43-21 — Reversed order — account number labelled before sort code

Should not match

Sort Code: 12-34-56 — Sort code alone with no account number anywhere nearby
Account Number: 12345678 — Account number alone with no sort code anywhere nearby
Invoice number 12345678 dated 12-34-56 — Two digit groups of the right shape but attached to unrelated labels (invoice/date, not sort code/account)

Known false positives

A 6-digit date-like or reference-like token near an unrelated 8-digit invoice/case number could in principle appear close together in a document without being real bank details. Mitigation: The regex requires the literal "sort code" label directly attached to the 6-digit group and the literal "account number"/"a/c no" label directly attached to the 8-digit group — bare digits next to unrelated labels (as in the should_not_match example above) do not match.
No modulus-check validator is available as a generic Purview function, so a structurally-matching sort code / account number pair is not confirmed to be a real, payable combination. Mitigation: Rely on the paired label-embedded regex plus evidence/noise-exclusion tiers; consider a downstream per-bank modulus check (Vocalink/Pay.UK weighting tables) for authoritative validation.