Coinbase and Robinhood returns can now be processed in RLEAPP. Our contributions add 14 Coinbase artifact types and nine Robinhood artifact types for supported legal-process return formats.
These returns can be useful in criminal defense and prosecution matters involving suspected fraud or cryptocurrency payments. An examiner may need to compare a reported transfer with an account change or other activity. Organizing those records helps an attorney understand the sequence while keeping each observation tied to its source.
That review can involve several provider-produced files. Account details may be in a CSV, transactions in another export, and account changes in a PDF. The new modules bring supported records into searchable reports and identify material that needs closer inspection.
Start with the records and their meaning
Before writing extraction rules, we needed to understand what the returns actually contained. Coinbase compliance reports use sections and tables within CSV files. Robinhood returns include several CSV and PDF formats, with account information, edit logs, statements, and activity spread across different documents.
Those differences matter. A second table inside a CSV section can have different columns. A wrapped line in a PDF can appear between two records. A timestamp can look complete while omitting its time zone. A crypto statement can contain an RHC account number alongside a separate RHS account number.
Report rows include references that help examiners find the source. Depending on the artifact, these include a filename, a CSV record number, a PDF location, or the source text. Converted timestamps also state the basis for the conversion.
If a split Account Master PDF has no account number, that field stays blank. A note explains the omission. The module does not assign an account simply because another PDF sits in the same folder.
These choices give examiners a clearer distinction between what a provider supplied and what the software derived.
Use AI to implement defined parsing rules
AI assisted with writing and revising code, generating synthetic test inputs, and running checks for unintended changes. It helped turn a defined parsing rule into an implementation and explore variations of the input.
We used a local LLM to turn information from the real returns into synthetic returns for development. We reviewed the synthetic returns for residual identifiers before using them with the frontier model or sharing them publicly. For parser development, the frontier model worked from those synthetic returns to help write the code.
Once the parsers were built, we ran the real returns through them and validated the output against the source records. We also checked determinism: repeated processing of the same inputs should produce the same parsed results.
That cycle took time. It was worthwhile because protecting the data and checking the output were part of the development work. The resulting validation applies to the returns and layouts we examined; it does not establish accuracy for every future production.
Decisions about what the records could support remained part of the human review. Could a timestamp be converted to UTC? Did a new row contain column headers? Could wrapped PDF text be assigned to one record without guessing?
AI helped write some of the code. Its output still had to be checked. We compared results with source records, ran repeatable tests, and reviewed the code and its limits. Examiners must still verify findings against the records in each matter.
Test failures as well as successful extraction
We built synthetic returns so that the tests could be shared and rerun without distributing case material. Those fixtures include multiple users, duplicate report copies, time-zone variations, unfamiliar sections, and deliberately problematic files.
Coinbase review exposed a simple but consequential problem. A valid CSV could be skipped when every cell was quoted. The detector checked the raw first line instead of the first parsed cell. We corrected that check and added a fully quoted report to the tests. A matched file that cannot be read as a report now produces a log message.
We also tested second tables within sections. Recognized headers use their own column order. Ambiguous header-like blocks go to Other Sections for inspection.
Duplicate report copies remain separate observations. Examiners should check the source files before treating repeated rows as separate events.
Robinhood review found a different failure. One damaged PDF could stop several artifacts from reporting valid records from other files. The correction handles that failure at the individual file. It logs the problem, adds a Parsing Notes row, and lets processing continue.
Protected PDFs and matched PDFs with unrecognized layouts also generate notices. A file that cannot be parsed should be visible to the examiner.
Following the corrections, the outputs for all 14 Coinbase and nine Robinhood artifact types matched their saved expected results. We also processed the synthetic returns through RLEAPP and checked the generated reports. These checks cover the tested inputs. Other production years and layouts may differ.
Review supported output and its limits
The modules produce the following artifact types. The names below omit the repeated provider prefix used in the report navigation.
| Provider and input | Report artifacts |
|---|---|
| Coinbase compliance report CSVs (14) | Subscriber Details; ID Verification Profiles; Phone Numbers; Previous Emails; Billing Addresses; Bank Accounts; Other Payment Methods; Crypto Addresses; Totals; Transactions; Exchange Activity; Account Events; Manual Reviews; Other Sections |
| Robinhood supported CSV and PDF formats (9) | Crypto Transfers; Crypto Orders; IP Log; 1099-B Detail; Account Master; Account Master Edit Log; Statements; Statement Activity; Parsing Notes |
These are the available report categories, not a promise that every return will populate every category. The 1099-B Detail artifact reads the supported CSV format; it does not parse PDF tax statements.
Parsing Notes are part of the examination workflow. They expose conditions such as an account number missing from a document, ambiguous wrapped text, or an unsupported layout. A report with warnings can still contain useful records, but the warnings tell the examiner where source review is required.
The source-to-report comparisons above come from synthetic test returns. They show how source values become report fields without exposing case records. The publication views show selected columns and obscure identifying fields; they are not substitutes for the complete examination reports.
Share work that began with our own analysis
The scripts began with a practical need in our own examinations: organize provider returns so we could review the records, follow source references, and identify questions needing closer attention. We built a custom report around that work, with account summaries, searchable tables, processing warnings, and activity charts.
We wanted the parsing work to be useful beyond our own workflow. Contributing supported readers to RLEAPP gave the community a way to use, inspect, test, and improve them within an established forensic tool. The custom report remains a separate presentation for our examination work.
The provider views show how that workflow supports review. Coinbase records can be organized into payment methods, provider-listed crypto receive addresses, and reported totals. Robinhood transfers can be filtered by type, asset, direction, and date before the examiner returns to the source for verification.
These views support analysis tailored to the questions in a matter. They help an examiner identify relevant periods, compare records, and recognize gaps. The interpretation still comes from the examiner and must be supported by the underlying records.
The report also provides an identity-image view with source references and an explanation of how each image was associated with an account. Where that association is inferred from a shared folder or ZIP, the report says so. That relationship alone does not verify the identity of the person pictured.
Use the output in an examination
Visit LEAPPs.org for tool downloads and documentation. In RLEAPP, look for entries beginning with “Coinbase Compliance Report” and “Robinhood Returns” in the artifact selection list. Select the applicable artifacts and process a working copy of the return. Record the RLEAPP version or commit used for the examination.
Review the tables and processing logs. For Robinhood, also read Parsing Notes. Compare relevant rows with their source records before relying on them in a finding.
Supported layouts have boundaries. Robinhood brokerage holdings are not mapped into the Statements holdings field. Missing time-zone information remains a limitation. A matching value also does not, by itself, establish ownership or identify the person responsible for an action. Checking whether a report supports that kind of conclusion is part of a law enforcement investigation review.
Thank you to Alexis Brignoni and the RLEAPP community for the careful review. The questions and failure cases strengthened both contributions. The implementation and review history are available in the Coinbase contribution and Robinhood contribution.
If you work with these returns, get RLEAPP through LEAPPs.org and try the supported modules, validate them against your inputs, and share reproducible issues using synthetic or appropriately sanitized examples. That feedback helps extend coverage while keeping the interpretation tied to the records.
Attorneys reviewing Coinbase or Robinhood returns are welcome to contact Cyber Agents to discuss examination needs, the available records, and the questions those records may help answer. We also provide expert testimony and trial consulting when findings need to be explained in court.