Account number format validated per region (IBAN/ABA)
Why it matters
IBAN and US ABA account numbers have structurally incompatible formats — IBANs are 15-34 alphanumeric characters with a country prefix; US account numbers are 8-17 digits. A single generic regex that accepts either format will reject valid inputs from one region and accept invalid inputs from the other. OWASP A03 and PCI DSS Req-6.2.4 require input validation appropriate to the data type. Misrouted payments due to format confusion create irreversible ACH or SWIFT transactions, customer losses, and regulatory liability.
Severity rationale
High because accepting incorrect account number formats routes payments to invalid destinations, causing irreversible transaction failures and potential fund loss.
Remediation
Use a discriminated union in src/lib/schemas.ts so each region's account number is validated against its own format rules, and route server-side validation through the same schema.
// src/lib/schemas.ts
const accountSchema = z.discriminatedUnion('region', [
z.object({
region: z.literal('EU'),
accountNumber: z.string().refine(validateIBAN, 'Invalid IBAN'),
}),
z.object({
region: z.literal('US'),
accountNumber: z.string().regex(/^\d{8,17}$/, 'US account must be 8-17 digits'),
}),
]);
Apply this schema in src/app/api/transfers/route.ts and mirror the same constraints in the client form component in src/components/.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the Financial Form Validation Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
External references
- cwe · CWE-20 — Improper Input Validation
- owasp:2021 · A03
- pci-dss:4.0 · Req 6.2.4 — Prevent common software attacks including injection and improper input validation
Taxons
History
- 2026-04-18·v1.0.0·Initial import from finserv-form-validation·automated