BTA / Delivery desk
Duplicate Trading Alerts and Idempotency
Repeated transport events must not silently become repeated trading instructions.
Separate an instruction from an attempt
An original instruction can travel through several delivery attempts. Keep a family ID, version and transport-event ID where the system supplies them. A retry relation explains why another payload exists. The same ticker alone is not a safe deduplication key: two legitimate decisions can concern the same instrument, while one decision can appear on several channels.
Never delete duplicate observations merely to simplify the history. Retain them with their relation to the original and record which destination saw each one. If identifiers are missing, state that exact duplicate classification is uncertain. A repeated text fragment can be evidence of similarity without proving shared instruction identity.
Define expected effects before testing
In an isolated synthetic test, declare whether a repeated message should be displayed again, recorded only or ignored for downstream action. An idempotent interpretation means repeated delivery does not add a second unintended effect. This is a proposed contract to inspect, not a guarantee about a vendor connector. The responsible receiver must supply its actual behaviour.
An amendment changes a known version; a retry repeats an attempt. A receiver that treats both as a new entry may lose the original history. Test the distinction with non-actionable objects, retain the expected state and compare it with actual logs. Do not attempt duplicate experiments on a live account solely for editorial evidence.
Report identity gaps openly
A log can contain repeated transport events without enough information to establish their effects. Request the destination acknowledgement or account event rather than guessing that a duplicate was harmless. Similarly, a lack of an extra position does not prove that all duplicate-handling branches are correct.
BTA's event ledger preserves event IDs and versions as reader notes. It does not enforce idempotency in an external service or certify a connector. A useful review identifies the original/attempt boundary and names the artifact required to demonstrate repeated delivery behaviour.
Original Evidence Packet
| Artifact | Record to retain |
|---|---|
| Identity | Family, version and transport-event identifiers |
| Expected effect | Declared retry interpretation in an isolated test |
| Actual effect | Receiver acknowledgement or unresolved gap |
Continue the Investigation
Source Boundaries
Official references describe published mechanisms. BTA's evidence packets and proposed test procedures do not claim a completed paid-feed or account trial.