BR-51 The payment card primary account number (BT-87) is 16 characters long, and BR-51 admits at most 10
The payment card primary account number (BT-87) is 16 characters long, and BR-51 admits at most 10. The PCI Security Standards Council permits an invoice to show the first six digits and the last four and nothing else, which is where the ten comes from. This is a warning rather than an error, so the document will be accepted — but an invoice is forwarded, archived, printed and emailed by people who never think of it as cardholder data, and a full PAN inside one puts every system it touches into PCI DSS scope. If it leaks, the disclosure obligation and the card-scheme fines are yours, not the validator's.
This rule is implemented and its error payload below is real, but the long-form write-up — normative text, worked example, divergence note — is not written yet. Everything the library knows about this rule is on this page. Ask and we will prioritise it.
- Business term
BT-87- Severity
warning
What the library returns
The exact object in result.errors when this rule fires.
Generated by running @attestwire/en16931, not transcribed:
{
"rule": "BR-51",
"field": "BT-87",
"severity": "warning",
"message": "The payment card primary account number (BT-87) is 16 characters long, and BR-51 admits at most 10. The PCI Security Standards Council permits an invoice to show the first six digits and the last four and nothing else, which is where the ten comes from. This is a warning rather than an error, so the document will be accepted — but an invoice is forwarded, archived, printed and emailed by people who never think of it as cardholder data, and a full PAN inside one puts every system it touches into PCI DSS scope. If it leaks, the disclosure obligation and the card-scheme fines are yours, not the validator's.",
"fix": "Truncate before you build the payload: set payment.card.primaryAccountNumber to the first six and last four digits only, e.g. \"411111\" + \"1111\" as \"4111111111\", or simply the last four. Never store or transmit the full number here.",
"example": "\"card\": { \"primaryAccountNumber\": \"4111111111\", \"holderName\": \"M Mustermann\" }",
"xpath": "/ubl:Invoice/cac:PaymentMeans/cac:CardAccount/cbc:PrimaryAccountNumberID",
"docsUrl": "https://attestwire.com/rules/BR-51"
}
xpath locates the element in the generated UBL document,
which is where a KoSIT or Peppol validator will report the same problem.
A passing value
"card": { "primaryAccountNumber": "4111111111", "holderName": "M Mustermann" }The fix
Truncate before you build the payload: set payment.card.primaryAccountNumber to the first six and last four digits only, e.g. "411111" + "1111" as "4111111111", or simply the last four. Never store or transmit the full number here.