What we aim to achieve
Detect inconsistencies
Goal: flag sales without a purchase, repeated rows and positions that do not add up.
Today: the engine covers only part of this (see “What exists today and what does not”).
Rebuild histories from documents
Goal: indicate which document is missing and, if there is evidence, propose how to recover the cost without inventing it.
Today: it does not exist. A manual simulation showed that it is possible.
Leave a traceable record
Goal: for every conclusion to state which file and row it relies on.
Today: the engine keeps the source of each row; a record the user can read does not exist yet.
Three common situations
A fictitious investor bought 100 shares of Security N at Broker Alfa (2021), transferred them to Broker Beta (2023) and sold 60 (2025). She only keeps Alfa's history from June 2022. Which document does she provide?
Broker Alfa history
| Date | Transaction | Quantity | Price | Amount |
|---|---|---|---|---|
| Before 06/2022: no document provided (the original purchase was here) | ||||
| 10 Mar 2021 | Cash deposit | — | — | $4,000.00 |
| 10 Mar 2021 | Purchase · Security N | 100 | $40.00 | $4,000.00 |
| 14 Jun 2022 | Cash deposit | — | — | $1,000.00 |
| 5 Sep 2022 | Purchase · Security Z | 50 | $12.40 | $620.00 |
This file records no outgoing movement of Security N: the transfer only appears at Beta.
Broker Beta history
| Date | Transaction | Quantity | Price | Amount |
|---|---|---|---|---|
| 16 May 2023 | Transfer in kind (incoming) · Security N Stated source: Broker Alfa · market value $4,500.00 | 100 | no price | — |
| 14 Feb 2025 | Purchase · Security Z | 30 | $15.00 | $450.00 |
| 12 Mar 2025 | Sale · Security N | 60 | $71.00 | $4,260.00 |
A $1.00 fee on each Beta transaction (not shown in the columns).
See the step by step (4 steps)
What happens with this sale?
- YES Detects that history is missing: it marks the sale as “unresolved cost” and warns of an incomplete history.
- YES Does not invent the gain: the result of that sale stays “not calculable”.
- NO Does not link the two brokers. The source (“Broker Alfa”) stays as a text note, but the engine does not use it.
- NO Shows 0 shares at Beta when in fact 40 remain (100 − 60). The internal accounting checks stay green (18 out of 18).
- NO Even if you provide Alfa's complete history, the engine does not link them: Alfa still shows 100 open shares and Beta's sale still has no purchase.
See the engine's literal warning
Without the 2021 purchase there is nothing to simulate: there is no cost to carry over. Any figure would be invented, and that is exactly what must not be done.
With Alfa's complete history, Alfa's outgoing movement was matched by hand and only in memory with Beta's incoming one (the outgoing movement had to be created and the security renamed so that the matcher would accept it). The cost carry-over mechanism that already exists was able to resolve the sale:
Amounts in dollars, before converting to euros. The engine does not accept the grey bar as valid. The $45 is an assumption of the case. This is not a tax calculation.
See the calculation
- Economic cost (60 sh.)
- $2,700.00
- Basis carried over from Alfa
- $2,400.00
- Gain with documented basis
- $1,859.00 (4,259 − 2,400)
- Difference between bases
- $300 (60 × (45 − 40))
What it shows: the idea is technically possible. What it does not show: that the link works for other portfolios, or that it already exists as a feature.
Units: INCOMPLETE Cost: INCOMPLETE
Message to the user: “I cannot calculate the gain on the sale of 12 Mar 2025: the 100 purchases that gave rise to the shares are missing. They arrived at Beta on 16 May 2023 from Broker Alfa, but the Alfa history you provided starts in 06/2022.” No cost is invented and no transaction is created.
Documents it would ask for
- The Broker Alfa history from the purchase (before 06/2022).
- A document from Alfa proving the outgoing movement of the 100 shares, or Beta's notice that states the source.
Proposed link: “Beta received 100 shares of Security N on 16 May 2023 citing Alfa as the source, and Alfa still holds exactly 100. Alfa does not document the outgoing movement, so I ask you to confirm the link.”
| Situation | Units | Cost |
|---|---|---|
| 1 · Complete history, link not confirmed | INCOMPLETE | INCOMPLETE |
| 2 · You confirm the link | UNVERIFIABLEprovisional | INCOMPLETEprovisional Tentative figure: 60 × $40 = $2,400 |
| 3 · In addition, Alfa documents the outgoing movement of the 100 | VERIFIED* | VERIFIED* |
A user confirmation allows a provisional figure to be shown, but it is not independent documentary evidence: on its own it is not enough for VERIFIED. In situation 3 there are two independent sources (the outgoing movement documented by Alfa and the incoming one documented by Beta). *Within the scope of the documents provided: it does not rule out movements outside them.
The historical cost is carried over from the documented purchase and nothing is invented.
Target result of the proposed design. It has not been built or tested beyond the manual simulation.
A Broker Beta file contains the same purchase twice: 30 shares of Security Z at $15.00, on 14 Feb 2025 at 11:20:00. Is it a duplicate or were there two real purchases?
| Row | Date and time | Transaction | Quantity | Price | Amount |
|---|---|---|---|---|---|
| 1 | 14 Feb 2025 11:20:00 | Purchase · Security Z | 30 | $15.00 | $450.00 |
| 2 | 14 Feb 2025 11:20:00 | Purchase · Security Z | 30 | $15.00 | $450.00 |
How can duplicates appear and why might they be legitimate?
How they appear
- Two overlapping exports are pasted together.
- The same period is downloaded twice under another name.
- The broker lists partial executions of the same order separately.
Why they might be legitimate
- Two different orders can be executed at the same price in the same second.
- A large order can be executed in two equal pieces.
- Deleting a real purchase makes it look as if you hold fewer shares than you do.
What does each one do?
YES Overlapping files
If you upload two Beta exports with transactions in common, the engine detects the repeated ones, excludes them from the calculation and links them to the original (it does not delete them). In the test: 2 duplicates discarded and a correct position of 40 shares of Security Z (30 + 10).
NO Repeated row in the same file
It counts them as two purchases: 60 shares instead of 30, with no warning at all. The accounting checks stay green (18 out of 18), because they check internal consistency, not reality. With a one-second difference between the two rows it does not warn either.
The ambiguity is real: without an execution identifier or other evidence, the engine cannot know whether there are one or two purchases. Today it assumes there are two.
Principle: the auditor does not remove ambiguous transactions. It keeps them all and decides according to the evidence. Choose what evidence there is:
Decision on row 2: probable duplicate → excluded reversibly, not deleted.
Status: UNVERIFIABLEprovisional
Why: the declared position (30) matches a single copy, but that figure comes from the same issuer and does not rule out that another movement is missing (for example an unrecorded sale of 30) that would also give 30.
For VERIFIED: a second independent source, such as cash movements or order confirmations.
Decision on row 2: two legitimate purchases are probable → both are kept.
Status: UNVERIFIABLEprovisional
Why: the declared position (60) only adds up if both purchases are real, but it comes from the same issuer and another omitted movement could offset the difference.
For VERIFIED: cash movements (two charges) or order confirmations.
Decision on row 2: undecided. Nothing is removed and the figure is not taken as good.
Status: UNVERIFIABLE
Why: it could be 30 or 60 shares and there is no source that settles it. The range (30–60) is shown and the positions statement is requested.
Decision on row 2: distinct transactions are probable → both are kept.
Status: UNVERIFIABLEprovisional
Why: the identifiers belong to the same file as the rows: they indicate that these are not copies, but they do not prove that nothing is missing. The final position still has to be cross-checked.
Decision on row 2: duplicate → excluded reversibly, not deleted.
Status: VERIFIED (within the scope of the documents provided)
Why: two sources that are independent of each other agree: the positions statement (30) and the cash account (a single $450 charge). It still does not rule out movements outside those documents.
Evidence that distinguishes a duplicate from a coincidence
- The position declared by the broker (one source, not independent of the same broker's transactions).
- The execution identifier, if the file includes it.
- Cash movements: how many charges there are.
- Whether the same file or the same period has been loaded twice.
Broker Beta's positions are calculated from its transactions and compared with those declared by the end-of-2025 statement itself.
| Security | Calculated | Declared | Difference |
|---|---|---|---|
| Security N | 0 | 40 | +40 |
| Security Z | 30 | 30 | 0 |
Calculated: the result of applying the current engine to Beta's transactions in example A (the engine does not count transfers in kind). Declared: open positions section of the fictitious statement.
Possible causes of the difference and documents to review
Most likely cause
In 2023, 100 shares arrived by transfer (with no purchase) and in 2025, 60 were sold: 100 − 60 = 40, exactly the difference.
Other causes that would need to be ruled out
- A transaction missing from the history.
- A transaction counted twice.
- An unrecorded stock split.
- A different cut-off date between the statement and the transactions.
Documentation that would need to be reviewed
- Beta's statement with the “open positions” section.
- Beta's notice of the transfer in kind (with the source).
- The Broker Alfa history, to recover the cost.
What does each one do?
- NO It does not compare declared positions with calculated ones. The importer recognises the open positions section of the statement, records it as a “snapshot” and ignores it; no component that cross-checks it was found in the code.
- Security N's position stays at 0 (“closed”) and the 18 internal checks stay green.
- There is a comparison against the position in one other specific type of statement, but it is not a general check between brokers.
Second independent source (only Security Z changes)
| Security | Units | Cost | What it would say |
|---|---|---|---|
| Security N | DISCREPANCY with the current calculation (0 versus 40) UNVERIFIABLEprovisional when counting the transfer in kind | INCOMPLETE | “I calculate 0 and the statement declares 40. Counting the incoming 100 shares and subtracting the sale of 60 gives 40, but both figures come from the same Beta statement and Alfa does not document the outgoing movement: I cannot rule out omitted movements. The cost is still pending: Alfa's history is missing.” |
| Security Z | UNVERIFIABLEprovisionalVERIFIED | UNVERIFIABLEprovisionalVERIFIED | “I calculate 30 and the statement declares 30. The purchase and the position come from the same Beta statement (a single source): they match, but I cannot rule out an omitted movement.”“I calculate 30, the statement declares 30 and the cash account records the charge for the purchase. Two independent sources agree, within the scope of the documents provided.” |
“Provisional” marks a tentative figure or decision that depends on a single source or on a user confirmation. VERIFIED is never provisional and always states its scope.
Overall portfolio result: INCOMPLETE while the cost of Security N remains pending. A portfolio with a significant mismatch is never marked as verified: the worst status prevails.
The four auditor statuses
◇ PROPOSED DESIGN They are part of the design of the independent auditor, not of a finished feature.
The checked data matches the available evidence, within the stated time and document scope.
Example: the calculated position matches the statement and another independent source.
Two documentary sources present incompatible information.
Example: your history says 0 and the statement says 40.
A transaction or document needed to rebuild the history is missing.
Example: a sale without the purchase that gave rise to it.
There are not enough independent sources to verify the result.
Example: two identical purchases and only one statement from the same broker.
Evidence rules of the design
- VERIFIED requires at least two documentary sources that are independent of each other. Two sections of the same statement count as a single source and are declared as such.
- A user confirmation is not documentary evidence. It allows a provisional figure to be shown, but not verified.
- That positions match transactions does not prove that nothing is missing: an omitted movement can offset another.
- “Provisional” marks a tentative figure or decision that depends on a single source or on a confirmation. It never accompanies VERIFIED.
- Units and cost are assessed separately: a position can have verified units and incomplete cost.
- Every verification states its scope (dates and documents) and certifies nothing outside it.
- In a portfolio the worst status prevails; with a significant mismatch it is never “verified”.
What exists today and what does not
Checked with the proof of concept on fictitious documents: 3 capabilities exist, 5 do not yet and 1 is out of scope.
See the full table
| Capability | Current engine | Future auditor |
|---|---|---|
| Alert when a sale has no purchase behind it | ✔ Yes (tested) | With explanation and a request for documents proposed |
| Link a transfer between brokers and carry over the cost | ✘ No Possible only with a manual simulation | With user confirmation proposed |
| Discard duplicates between overlapping files | ✔ Yes (tested) | Kept |
| Detect a repeated row within the same file | ✘ No | Without deleting; decides according to the evidence proposed |
| Correct a small price error between two sources (≈3%) | ✔ Yes (tested) | Kept |
| Prevent a large price or quantity error from creating an additional transaction | ✘ No (it duplicates the purchase) | It would flag it as a discrepancy proposed |
| Compare calculated positions with those declared by the broker | ✘ No, not in general | With four statuses proposed |
| Process a portfolio with only these brokers, without depending on our own portfolio | ✘ Not without changes | Independent module proposed |
| Tax calculation | ✘ Not the goal of this demonstration | ✘ Not included |
Want to know when it is available?
This page does not send or save anything. Early access is not open yet: when it is, you will be able to sign up from the main page.