An exchange export may look like an ordinary spreadsheet: dates, assets, amounts, and fees. Yet uploading it to an external AI tool can also disclose wallet addresses, connections between accounts, and information about the size of your holdings. Even without a name, the records may be matched to a public blockchain, revealing much more about their owner than an expense analysis requires.
The safer starting point is a specific question, not a file upload. Identifying expensive withdrawal methods requires different fields from comparing monthly expenses. The process below uses a fictional example to explain data preparation. It can reduce disclosure, but it does not make a financial history guaranteed anonymous.
What financial AI needs to know about your transactions
Separate calculation from explanation. Totals, currency conversion, and grouping can be handled locally in a spreadsheet. You can then give an external assistant a small summary and ask it to explain the expense breakdown or suggest checks. A narrower task gives you fewer reasons to disclose your entire portfolio history.
For example, at https://www.numevia.io/, NUMEVIA advertises transaction, expense, and income analysis, alongside report generation. This illustrates how a financial AI service positions itself; it does not confirm support for cryptocurrency CSV files. Its Terms of Service describe the current build as a front-end demo and state that outputs are not financial advice. These claims do not establish a tested workflow for importing exchange records.
To answer “which transaction types account for the highest fees?”, the period, transaction category, network, and fee amount in a chosen currency will often be enough. Wallet balances, recipient addresses, email addresses, and exchange account numbers are unnecessary for that comparison. Retain an asset ticker only when it affects the answer.
Calculating fees as a share of transaction volume also requires transaction amounts, measured using a defined method. If you only need changes in spending, you can omit volume entirely. The question should determine the minimum dataset—not the columns provided by the exchange. Write the purpose in one sentence and justify each field you retain.
Why a CSV without your name can still identify a wallet owner
A transaction hash points to a specific record on a public network. An address exposes its transaction history, while a combination of precise time, asset, and unusual amount may help locate a transfer even after its hash has been removed. If the owner has already published one connected address, matching becomes easier. Removing a name does not eliminate these links.
Replacing an address with “Wallet A” is pseudonymisation, not automatic anonymisation. A stable label still connects rows, and a mapping file can restore the original values. Predictable hashing of an address is no guarantee either: someone can process a known public address in the same way and compare the result.
In the version adopted on 16 January 2025 for public consultation, the EDPB’s Guidelines 01/2025 on Pseudonymisation explain the distinction between pseudonymisation and anonymisation. Additional information used to restore links needs to be separated and protected; other attributes may also need removal or generalisation. For a crypto export, the practical lesson is to examine the remaining combination of details, not just the identifier.
Pay particular attention to rare events: a single large NFT purchase, a transfer involving an illiquid token, or an unusual sequence of swaps. Sometimes it is safer to exclude the event from the external dataset and analyse it locally. Do not call a file anonymous simply because addresses have been replaced with labels.
How to prepare a minimal dataset locally: a worked example
Suppose an investor wants to compare fees for January and February. The fictional history contains four transactions: a January purchase with a €2 fee, a withdrawal with a €3 fee, a swap with a €1 fee, and a February withdrawal with a €4 fee. The comparison needs no recipients, asset balances, or precise transaction times.
- Keep the original separate. Work on a copy in a local editor without automatic cloud synchronisation. Retain the original for reconciliation and recordkeeping; the cleaned file does not replace it.
- Standardise the values. Check decimal separators, time zones, and fee currencies. If a fee was charged in cryptocurrency, calculate its equivalent locally using a chosen exchange-rate source and record your method.
- Remove unnecessary columns. For this example, exclude addresses, hashes, order numbers, account identifiers, names, email addresses, payment details, and balances. Review comments too: they may contain counterparty notes or blockchain explorer links.
- Use labels only for necessary relationships. If comparing platforms matters, use “Platform A” and “Platform B”. Keep the mapping separately and do not send it with the dataset. If platform comparisons are unnecessary, remove those labels as well.
- Aggregate to the required level. This example needs only two rows: January—€6 in fees; February—€4. For a breakdown by transaction type, retain monthly category totals rather than individual transactions.
- Reopen the final file. Inspect headings, every remaining column, and text fields. Confirm that you exported only the intended sheet and did not attach the original workbook.
Generalising dates and amounts serves different purposes. Replacing a timestamp with a month reduces the precision of time-based matching. Rounding amounts or using ranges reduces detail further, but can distort calculations. If exact totals matter, calculate them locally first and share aggregates. Where even aggregates present a disclosure risk, ranges may be preferable, with the understanding that the AI can provide only an approximate explanation.
Do not delete reconciliation fields before completing local checks. A transfer identifier, for example, may help establish that an exchange withdrawal and a receipt in your own wallet represent one transfer. It is useful during preparation but not necessarily for external analysis. After matching the records, assign a local “internal transfer” category and exclude the original identifier from the export.
For an initial test, create entirely fictional rows rather than slightly altering real amounts. This lets you check whether the assistant understands the request without disclosing your history. A successful test proves neither secure processing nor accuracy on more complex data.
How to check that cleaning has not distorted fees and expenses
Before sending anything, compare control figures between the original and prepared data: the period covered, the number of transactions included before aggregation, category totals, and total fees. In our example, the four original fees total €10. The two-row monthly summary must preserve that result: €6 plus €4. Fewer rows are expected here; missing expenses are not.
Check what the money movements represent. Moving funds between your own wallets does not, by itself, turn the full transfer amount into income or an expense, although the fee may be recorded separately. Buying an asset is not equivalent to losing the entire purchase amount. Define categories explicitly for expense analysis; tax classification is a separate question that depends on the jurisdiction.
A common error is adding a fee twice: it is already included in the total debit but also appears in a separate field. Another is adding fees in BTC, ETH, and euros as though they were comparable numbers. Document which values include fees, how conversion works, and where data is missing. Do not silently replace a missing value with zero.
A suitable prompt might be: “These are monthly fee totals in euros. Compare the periods and calculate the absolute and percentage change. Do not infer portfolio returns or reconstruct missing transactions.” In the example, fees fell by €2, or approximately 33.3% relative to January. That does not prove rates became cheaper: transaction counts and types may have changed.
Ask the assistant to separate observations from hypotheses and identify missing information. Then independently recalculate the key figures. Confident wording is no substitute for checking original records, especially when dealing with profit, asset cost basis, or tax obligations.
What to establish about a provider before sharing real data
Minimisation reduces the consequences of disclosure, but it does not replace checking the recipient. NUMEVIA says it uses modern encryption technologies and secure infrastructure in its company profile, О компании NUMEVIA (About NUMEVIA). This is the provider’s own description, not independent verification of security. It does not, by itself, answer questions about file retention, employee access, subcontractors, or the use of data for training.
Before sharing information, establish whether original files and conversation histories are retained, where they are processed, who can access them, and how they are deleted. Ask whether deletion covers backups, whether training use can be disabled, and which third-party models receive prompt contents. For API use, separately examine key permissions and logging: an integration interface does not imply restricted access by default.
OWASP’s LLM02:2025 Sensitive Information Disclosure identifies financial data and credentials among sensitive information. Its recommendations include sanitising inputs, applying least privilege, and restricting data sources. A prompt saying “do not disclose this information” is not a security guarantee; it cannot replace access controls and data-handling rules.
Seed phrases, private keys, passwords, recovery codes, and API secrets should never enter an analytical export. Explaining expenses does not require connecting a wallet, signing a transaction, or granting withdrawal permissions. If a real workflow requires an integration, assess its permissions and risks separately from the quality of AI responses.
If storage and usage terms remain unclear, keep calculations local and share only a fictional example or a general question without transaction history. A practical readiness test is whether you understand why every field is needed, have reconciled the totals, and can accept the consequences of disclosing this reduced dataset. If not, reduce it further—or do not send it.
