Most counterparty confirms arrive as plain-text email or PDF attachment, not as a structured feed. A broker might send a five-line confirmation with no consistent field order. A prime counterparty sends a PDF with a table. A smaller dealer sends a paragraph in the body of the email with no labels at all, just numbers in sequence. The ops desk reads all of them the same way: a human opens each one and enters the fields into a spreadsheet. Catena reads them the same way a machine can, without writing a custom template for each counterparty. This is a walkthrough of the parsing logic and where it falls short.
Why Plain-Text Email Confirms Are a Harder Parsing Problem Than They Look
A structured API message carries field labels. A FIX message tag 48 is always the security identifier. Tag 32 is always the last quantity. When the label travels with the value, extraction is mechanical.
Plain-text email has no such guarantee. One counterparty writes "ISIN: US0378331005" and another writes "Security: AAPL (US0378331005)" and a third writes "traded 500 shares Apple Inc 0378331005." Three different formats, three different positional relationships between label and value, and all three need to produce the same ISIN extraction.
The added difficulty is that confirms contain multiple numeric fields in close proximity: quantity, price, notional, accrued interest, settlement amount. A parser that only looks for "the first number" gets the wrong field a significant portion of the time. Context matters, and context in free-form prose is not structured.
The Four Fields Catena Extracts from Every Confirm
Instrument Identifier: ISIN and the Identifier Conversion Problem
Catena looks for ISIN as the primary identifier: a 12-character alphanumeric string beginning with a two-letter country code, followed by nine digits, then a check digit. That format is specific enough to extract by pattern in most cases.
The problem arises when the confirm carries a CUSIP instead. CUSIPs are nine characters and do not carry a country prefix. Catena converts CUSIP to ISIN automatically for US securities by prepending "US" and computing the ISIN check digit. For positions where the counterparty sends neither, but sends a ticker or a short name, Catena flags those for manual review rather than guessing at an identifier. Instrument identification is the field where silent errors compound, so a low-confidence extraction is not surfaced as a match attempt at all.
Quantity: Units Versus Face Value
Equity confirms express quantity in shares. Bond confirms express quantity in face value, typically in thousands. A confirm that says "1,000,000" on a corporate bond position means one million dollars face value, not one million bonds. A matching engine that treats those as the same number produces a false match on a position with very different economics.
Catena infers the quantity expression type from the instrument class identified in the earlier step. When the ISIN resolves to an equity, quantity is treated as units. When it resolves to a fixed income instrument, quantity is compared against the position record's face value field. If those two fields are missing or ambiguous, the confirm is flagged rather than auto-matched.
Price: Clean Price and the Accrued Interest Question
Equity price extraction is straightforward in most confirms: a single dollar amount per share. Bond price is more complex. Confirms may express a clean price (flat price without accrued interest), a full price (dirty price including accrued interest), or both. Two confirms on the same trade from different counterparties frequently show different price numbers because one sends clean and the other sends dirty.
Catena normalizes to clean price for matching purposes. When a confirm carries both a price and an accrued interest field, the accrued amount is subtracted from the full price to derive the clean equivalent. When only one price is present and it cannot be determined from context whether it is clean or dirty, the field is extracted with a confidence flag and the match is held for review if the price delta exceeds the desk's configured tolerance.
Settlement Date: Calendar Differences and Non-Standard Cycles
Settlement date should be the easiest field to extract. It appears as a date string, usually in ISO 8601 format or a regional variant. The extraction is rarely the problem. The mismatch is.
US equity settlement follows a T+1 cycle. US corporate bonds generally settle T+2. Municipal bonds can settle T+2 or T+3 depending on the counterparty convention. When a confirm carries a settlement date that differs from the desk's internal trade record by one business day, the cause is frequently a different holiday calendar, not an error. New York Stock Exchange holidays and Federal Reserve settlement holidays do not always align. A confirm generated by a counterparty in London may reflect Bank of England holidays that the desk's system did not account for.
Catena flags settlement date mismatches but does not treat all of them as errors. A one-business-day gap on a cross-border position gets routed to a calendar-check queue. A two-day gap is escalated as a genuine discrepancy.
Handling Format Variation Without Writing Custom Rules
A template-based parser requires a counterparty template for each sender. That means someone has to build and maintain the template. When a counterparty changes their confirm format, someone has to update the template. At a desk with 30 active counterparties, the template maintenance burden is meaningful.
Catena does not use counterparty-specific templates for the core parsing pass. Instead, the parser applies contextual pattern recognition: label scanning within a window of characters around each extracted value, positional heuristics specific to financial confirm structure, and a validation pass that checks extracted values against instrument reference data. If the extracted ISIN check digit is invalid, or the extracted price is outside a plausible range for the instrument type, the extraction is rejected and the confirm queues for review.
Consider a mid-tier broker-dealer that sends confirms as unstructured PDF attachments with a non-standard table layout for repo transactions. The PDF text extraction produces a block of characters where the label-value relationship is lost in the conversion from column layout to flat text. In that case, Catena cannot extract fields with sufficient confidence to attempt a match. The confirm lands in a manual review queue with the extracted text available for the ops analyst to reclassify. This is not a failure of the system; it is the correct behavior when confidence is insufficient.
What Happens When Parsing Confidence Is Low
Catena surfaces two types of parsing outcomes. A high-confidence extraction produces a match attempt against the desk's open position records. A low-confidence extraction, or a partial extraction where one or more required fields could not be resolved, produces a flagged item in the review queue with whatever fields were successfully extracted pre-filled.
The review queue item shows the original email text alongside the extracted fields so the analyst can confirm or correct each one. Corrected fields feed back into the extraction model as signal over time, which means the system improves on the specific counterparty formats it sees repeatedly. Custom template maintenance is not required, but the correction feedback is the functional equivalent of it.
We should be clear about what this approach does not do: it does not eliminate manual review entirely. Some confirms will always require a human look. The goal is to reduce the volume of confirms that require manual entry from 100% down to a small fraction, specifically the ones where the format is genuinely ambiguous or where the counterparty's conventions differ enough that automated extraction would carry unacceptable error risk.
The Parsing Step and What Comes After
Parsing is the first step in Catena's matching chain. A successfully parsed confirm feeds into the matching engine, which compares the extracted fields against the desk's open position records: ISIN, counterparty identifier, quantity, price within tolerance, and settlement date. The break alert fires when any of those fields fails to match within defined thresholds.
The parsing step is also the hardest part of the chain to test, because the inputs are unrestricted free-form text from dozens of counterparties. Every edge case that has appeared in production parsing, from Roman numeral date formats to confirm emails where the price is expressed as a yield to maturity, becomes test data for the next iteration.
If your desk is dealing with counterparties whose confirms require manual re-entry every day, the first question to ask is whether it is a format problem or a field-order problem. Format problems, where the confirm is a non-standard PDF or image scan, require a different solution than field-order problems, where the confirm text is parseable but the fields appear in an unusual sequence. Catena handles the second category well. Arbitrary layout PDF extraction is on the product roadmap, but we are not claiming it works reliably on all formats today.
