Merchant enrichment does not need full statements, customer names, bank credentials, card numbers, account numbers, emails, phone numbers, or addresses. The useful unit is one descriptor plus limited context such as amount, currency, country, and MCC when available.
PAYPAL *ACME SUPPLY 4029357733This descriptor can be normalized as a PayPal-wrapped merchant candidate. It should not be submitted together with the cardholder name, statement PDF, account number, or surrounding transaction history.
Request shape
{
"raw_description": "PAYPAL *ACME SUPPLY 4029357733",
"amount": 42.10,
"currency": "USD",
"country": "US",
"mcc": "5943"
}The request is intentionally narrow. Privacy rejection should run before parsing, matching, cache-miss handling, logging, support tooling, or third-party use. If the input looks like a statement or contains sensitive identifiers, the API should return a bounded rejection instead of trying to salvage a result.
When to use it
Use this pattern when your application already has a transaction row and needs a cleaner merchant label, category hint, confidence score, warning list, or logo-ready metadata. It is a fit for product UI, import cleanup, budgeting, expense review, and lightweight reconciliation workflows.
When not to use it
Do not send a full bank export for convenience. Do not submit customer identity fields because they happen to be adjacent in your database. Do not treat enrichment as a replacement for consented bank-data handling, fraud investigation, or compliance review.
Privacy caveat
For audit requests, use anonymized descriptors only. The safe boundary is narrower than many internal logs: one descriptor, limited transaction context, and no customer PII. TxnKit's public copy and API contract are built around that boundary rather than around bulk statement upload.