Break the description into evidence fields
Parse available clues into the payment rail, processor, merchant or counterparty fragment, status, location, card suffix, reference, and embedded date. Keep those fields beside the untouched source string.
Uppercase text does not necessarily name the merchant. ACH originators, facilitators, wallets, ATM operators, marketplaces, and bank labels can precede or replace the recognizable counterparty.
Take the fictional string ACH CREDIT ACME PAY 483920 PPD. It contains a rail, direction, possible originator fragment, possible trace or batch fragment, and payment-class code, but none independently establishes commercial purpose. Preserve the full string, parse each clue separately, and confirm a counterparty only from supporting receipts, account records, or a bank trace.
Parse a descriptor into clues without turning clues into facts. Consider the fictional text WEB CREDIT NORTHSTAR PAY REF7741. WEB suggests a channel, CREDIT gives direction, NORTHSTAR PAY may identify an originator, and REF7741 may be a trace fragment. None of those pieces alone establishes purpose. Store them separately, preserve the complete source string, and attach a confirmed counterparty only when a receipt, account record, or institution trace supports the interpretation.
Use account context cautiously
Use value, direction, date, card, neighboring activity, receipts, and merchant accounts to test an identity. Context may corroborate a likely match, but it cannot justify inventing a missing name.
Stable reference fragments can support grouping without revealing the merchant. Strip changing numbers only from a normalized field and preserve them in the original description for trace work.
Treat reference numbers as matching clues, not public identifiers. Compare only the fragments needed to connect a receipt, wallet entry, or bank trace, and mask them in shared review notes. A repeated prefix may identify a processor while the changing suffix distinguishes individual events, so preserve both the normalized pattern and the protected source value.
Handle payment intermediaries
Wallets, marketplaces, processors, and payment apps can obscure the underlying seller. Verify the matching receipt or account through an official route, then store the confirmed seller in a separate analytical field.
The same intermediary may carry transfers, purchases, refunds, and cash-like activity. Direction and supporting records, not the intermediary label alone, should determine classification.
Intermediaries make identity matching error-prone because a wallet label can remain stable while sellers change, and a marketplace prefix may cover purchases, fees, refunds, or transfers. Normalize in layers: rail, intermediary, verified seller, purpose, and confidence. Apply category logic at the deepest supported layer and return intermediary-only cases to review.
Model payment platforms separately from the seller. A wallet name can repeat even when the merchant behind it changes, while the same platform may process purchases, reimbursements, service charges, and transfers. Keep channel, platform, possible merchant, confirmed merchant, purpose, and confidence in distinct fields. Categorization should rely on the most specific identity that evidence supports; when only a platform is known, send the entry back for review. Otherwise, a recognizable platform name can create confident but unrelated merchant and category assignments.
Description investigation log
Maintain a clear boundary between the bank's source text and conclusions supported by later evidence.
Source string
Retain the full description verbatim, including all suffixes and reference fragments.
Parsed clues
Extract payment channel, processor, location, card ending, and stable reference elements.
Verification
Cite the receipt, merchant record, bank trace, or official source supporting the conclusion.
Conclusion
Record normalized merchant, category, confidence, and open questions without modifying the source evidence.
Escalate unfamiliar entries safely
Retain the posted wording, value, date, account, and page location exactly. Through an official contact number, ask the institution for trace or merchant information available for that payment rail.
Avoid public screenshots or crowd-sourced identification that exposes account data or spending history. If the transaction may be unauthorized, use the institution's formal process without delay.
For an unknown description, open an investigation record rather than guessing. Preserve the account, exact text, value, date, direction, page, card suffix, and neighboring balance; then check receipts and official merchant or wallet records before requesting a bank trace if needed. Record each source's finding, keep confidence with the normalized name, and leave the bank text untouched for reconciliation or dispute work.
For a card descriptor that is still unfamiliar, follow the unrecognized credit card charge review before disputing or accepting the transaction.
For short bank-specific codes inside the description, consult the bank statement abbreviation reference and confirm the meaning with the institution when needed.