Post-Trade Processing

Tanya, 34, trade operations analyst, only sees the consequences after the fact: a trade that should match fails because the instrument identifier differs by one character; a corporate action entitlement goes missing because the record date basis arrived as a free-text string; a settlement instruction gets rejected because the currency field arrives as “USD” in one feed and “US DOLLARS” in another. These are not rare corner cases. They happen when front office systems produce data in one structure, confirmations arrive in another, and post-trade systems demand a strict format with controlled values.

Your intake job sits between those worlds. You capture what the front office sends, validate it so it meets minimum correctness rules, and normalize it so every downstream process reads the same meaning from the same fields. When intake does this well, reconciliation breaks turn into true economic or event mismatches. When intake does it poorly, reconciliation breaks become noise you must clean up before you can even start the real work.

This chapter focuses on one practical lever: a repeatable intake routine that you can run every trading day. You will not rely on “looks right” checks or tribal knowledge about which feed usually wins. You will apply consistent validation and normalization rules to build a Clean-Path Intake Checklist package - data that stays stable as it moves through reconciliation, corporate actions processing, and reporting.

How it works: capture, validate, and normalize into a Clean-Path Intake Checklist

A clean intake path uses three ideas in sequence: capture the raw trade data with traceable references, validate it against rules you can explain to audit, then normalize it into controlled formats so downstream systems stop guessing. The goal is not to “clean everything.” The goal is to make downstream processing deterministic: the same input shape produces the same output shape, and any exception routes to a clear fix workflow.

Use the Clean-Path Intake Checklist to standardize your work. The checklist forces you to treat each trade as a structured record, not a collection of fields you hope will line up later.

1. Capture with traceable identifiers (raw in, references intact). Store the incoming trade payload as-is and capture the front office reference (trade ID), the confirmation reference (if present), and the timestamp you received it. If your system ingests via file transfer or API, record the source name and file/batch ID. This prevents “which version did we use?” debates when two feeds arrive for the same trade.

2. Validate mandatory fields and controlled values before you touch normalization. Check that required fields exist and meet basic format rules (length, character set, date format). Then validate controlled vocabularies: for example, enforce “Settlement Currency” as ISO-style currency codes like USD, EUR, or GBP instead of free text. If a required field fails, route the record to a correction queue and stop normalization for that record.

3. Normalize instrument, parties, and money fields into consistent formats. Convert instrument identifiers into your post-trade canonical form (for example, map ISIN to internal instrument ID; if you only receive a ticker, you must resolve it to the internal ID using your instrument master). Normalize dates into one timezone convention and one date basis (trade date, execution date, settlement date, and corporate action relevant dates). Normalize numeric fields by removing formatting differences (no commas, consistent decimal precision).

4. Validate cross-field logic so you catch “technically present but economically wrong.” Confirm that the fields agree with each other. If a trade states a settlement date that predates the trade date, flag it. If the notional currency differs from the pricing currency in a way your product rules do not allow, flag it. This step catches the “everything exists, but meaning changed” errors that later break reconciliation.

Concrete example: Tanya receives a daily trade feed for equity trades. One record arrives with Settlement Date formatted as 08/01/2026 and another arrives as 2026-08-01. If she normalizes dates without first validating date format and basis, she risks swapping month/day for the first record in systems that treat ambiguous formats differently. If she validates first, she can reject or correct the ambiguous date format before it becomes a settlement mismatch.

Normalization also matters for corporate actions eligibility. A trade that looks correct in the front office can fail entitlement if the record date basis or entitlement classification arrives as a free-text label. When intake normalizes those fields into controlled values, corporate actions processing stops treating each label as unique.

Putting it into practice: run the intake pass on a real trade package

You need a routine you can execute fast under time pressure, and you need outcomes you can verify. Here is a realistic flow Tanya uses when the morning feed lands and multiple downstream jobs wait on a clean package. Assume the post-trade systems do not accept free-text for key fields and they expect normalized identifiers.

1. Ingest and lock the raw records for the batch. Tanya ingests the file and captures: source name, batch ID, and receipt timestamp. She also stores the raw payload and the front office trade ID for each record. Expected outcome: you can re-run the intake logic later against the same raw input.

2. Run the Clean-Path Intake Checklist validation rules on each record. She validates mandatory fields first: internal instrument ID (or resolvable identifier), trade date, settlement date, side (buy/sell), quantity, currency, and counterparty references. She also checks controlled values for currency codes and side values. Expected outcome: records either pass to normalization or land in an “intake exception” queue with a reason.

3. Resolve and normalize identifiers. For each record, Tanya resolves instrument identifiers using the instrument master. If the feed provides ISIN, she maps to the internal instrument ID. If it provides only a ticker, she resolves using symbol + exchange + country, not symbol alone. She normalizes currency to the code format and quantity to consistent decimal rules. Expected outcome: every normalized trade record uses the same internal IDs and the same field formats.

4. Check cross-field logic for consistency. Tanya checks: settlement date is not before trade date; quantity sign matches side; currency matches the expected product rules for that instrument; and the notional amount equals quantity times price within the tolerance your system allows (if price exists). Expected outcome: you catch economic inconsistencies before reconciliation.

5. Publish the normalized trade package to downstream staging. She writes the normalized records into the post-trade staging area with a single “normalized version” identifier and the original raw references. Expected outcome: downstream jobs read stable data without needing to guess.

6. Run a reconciliation pre-check on the staging output. Tanya runs a quick match check using the normalized references against confirmations or existing records. She expects a defined behavior: for example, records that already exist should match on trade ID and quantity; new trades should appear with no breaks. Expected outcome: you detect systemic mapping issues (like a broken instrument master mapping) before settlement workflows start.

Quick checklist (what Tanya actually does every time the feed lands) - Capture raw payload with batch ID and front office trade ID. - Validate mandatory fields and controlled values (currency codes, side, date formats). - Resolve instrument identifiers using symbol + exchange when needed. - Normalize dates and numeric formats into your post-trade conventions. - Validate cross-field logic (dates, side/quantity sign, notional math when available). - Publish to staging with normalized version ID and raw references. - Run a staging pre-check so you catch systemic break patterns early.

What to watch for: common mistakes and edge cases that break intake

Even with a checklist, teams hit predictable failure modes. The fastest way to improve your intake is to recognize these patterns and fix the process, not just the specific trade.

Ambiguous dates sneak through Teams often treat date strings as “good enough” until settlement breaks. The fix starts earlier: validate date format and basis before normalization. Do this: Reject any date field that does not match your accepted formats (for example, enforce YYYY-MM-DD for settlement date) and require a correction from the feed owner or a mapping rule. Not this: Convert dates opportunistically based on locale settings or “looks like August” assumptions. You will eventually swap month/day and create settlement mismatches that reconciliation cannot explain.

Instrument resolution picks the wrong mapping A ticker without exchange, or an ISIN that maps to multiple instrument variants in your master, can land you on the wrong internal instrument ID. Downstream then treats the trade as a different product. Do this: Resolve instruments using the full key your master expects (for example, ISIN alone if it is unique; otherwise symbol + exchange + country). Log the mapping key you used for each normalized record. Not this: Resolve using ticker only because “most of the time it works.” When it fails, it fails quietly until corporate actions entitlement and reporting produce inconsistent results.

Cross-field logic passes even when economics changed A feed can provide all required fields but still carry the wrong meaning: side and quantity sign disagree, settlement date rules conflict with product conventions, or currency mismatches pricing assumptions. Do this: Add cross-field checks that reflect how your products behave. Use rules like “side must match quantity sign” and “settlement date must not precede trade date.” Apply notional math checks when price exists. Not this: Validate fields independently and skip the cross-field logic. You will push bad meaning into normalization and force reconciliation to become a second intake step.

These edge cases matter because they show up downstream as reconciliation breaks, corporate action entitlement gaps, and reporting inconsistencies that you cannot correct quickly once positions build. Good intake keeps the problem small and traceable: you fix one record with a clear reason, update the mapping rule if it repeats, and keep downstream workflows moving.

If you treat intake as a controlled transformation - raw capture, rule-based validation, then deterministic normalization - you stop fighting your data and start using it. That discipline becomes the foundation for the reconciliation and corporate actions work that follows, without turning your post-trade team into a permanent exception-handling desk.

End of chapter one. 7 more chapters in the full book.