Start from exports your systems already produce
The starting method is agreed CSV or JSON exports from authorized systems. Nothing is shown as connected until that connection has been verified.
Agreed exports come first
You export the records for one workflow. We validate each file before it is used and show any rejected rows, so the export can be fixed.
- Format
- CSV or JSON, agreed for each source
- From
- Systems you authorize for the workflow
- Sent by
- The transfer method approved in the written scope
- Never by
- Email or the public demo form
The records each workflow needs
These are types of record, not named vendor products.
Forex brokers
- Payment status export
- Wallet journal
- Transfer instructions
- Trading records
- Explicit account mappings
Prop firms
- Order and payment records
- Purchased entitlement
- Account provisioning records
- Account reference mappings
- Approved rewards and payouts, if in scope
Crypto exchanges
- Custody or network deposit data
- Internal customer ledger
- Customer attribution records
- Asset register with network and scale
- Acceptance rule for each asset
Three connection statuses, and what each one means
Today every route is export-based. No vendor connection is shown as verified.
Agreed CSV or JSON exports from an authorized system. This is the starting method.
A proposed connection is being tested against known outcomes. Nothing relies on it yet.
Shown only after that vendor and version pass acceptance tests.
Proposed connections today
Payment or order export
Forex, Prop
Export-basedWallet journal
Forex
Export-basedTrading records
Forex
Export-basedAccount provisioning records
Prop
Export-basedCustody or network deposit data
Crypto
Export-basedInternal customer ledger
Crypto
Export-based
Every row belongs to a named entity and account
Mappings are explicit. Accounts in different systems are linked by agreed identifiers and a date range, never by guesswork.
A mapping states
- Legal entity
- The approved entity the rows belong to
- Source account
- The identifier exactly as the export states it
- Mapped to
- The explicit match in another source
- Effective interval
- When the mapping applies
Each result carries the coverage behind it
Coverage is the time period, filters and known gaps of each export. A missing export does not prove a missing credit.
Wallet journal
Registered export source
- Covered interval
- 1 Nov 2026 00:00 to 7 Nov 2026 23:59 UTC
- Exported
- 8 Nov 2026 06:10 UTC
- Known gaps
- None declared
Wallet journal
Registered export source
- Covered interval
- 1 Nov 2026 00:00 to 7 Nov 2026 23:59 UTC
- Exported
- 8 Nov 2026 06:10 UTC
- Known gaps
- 4 Nov 2026 02:00 to 05:00 UTC. A missing export does not prove a missing credit.
Wallet journal
Registered export source
- Covered interval
- None. The source is registered and has never sent records.
- Exported
- Never
- Known gaps
- Not applicable
We approve a route before relying on it
1
Look at a small sample
A small sample with only the fields the workflow needs.
2
Agree the format
Columns, identifiers, units and time zone are written down.
3
Test known outcomes
The route runs against cases whose answer is already known.
4
Approve the route
Only then is the source used for a review.
Questions about data
Can PipsClarity work from CSV exports?
Yes, agreed CSV or JSON exports are the starting method. Each file is validated before use, and rejected rows are shown so the export can be fixed.
Do you need access to our systems?
No, you send agreed exports by the transfer method approved in the written scope. PipsClarity does not need logins to your payment, trading or custody systems to start.
Why does coverage matter?
Because a gap in an export can look like a missing credit. Each export states the period and accounts it covers, so a result never claims more than the records can support.
Talk to us about your sources
Request a demo and tell us which systems hold the records. Please do not send files through the form.