Source of Funds: the complete guide to proving where your crypto came from
The source of funds request always arrives at the worst moment: when the money is already on the exchange, or already on its way to a bank. From there it is not persuasion that decides the outcome, it is whether your documents agree with each other and whether you closed the one gap that breaks most files, the step from fiat to crypto. This is the guide we work from.
In years of doing this I have never seen a case won by a convincing explanation with no paperwork behind it. I have seen dozens won by a boring, meticulous file put together by someone with no legal training at all. Compliance does not grade your sincerity. It reconciles your statements against documents and looks for gaps. A source of funds request is not a test of honesty, it is a test of consistency.
Source of Funds and Source of Wealth are not the same request
This is the single most common mix-up, and it costs people weeks. Source of Funds (SoF) concerns specific money in a specific transaction: where exactly the 20,000 USDT you deposited in March came from. Source of Wealth (SoW) concerns your capital as a whole: how you acquired what you own.
Institutions blur the two in their own templates all the time, or ask for both at once. Assemble the wrong one and the first reply you get is "the documents provided do not address the request", while the clock keeps running. So step zero never changes: read the wording of the request literally and write down three things. What is being asked for (SoF, SoW or both), for which period, and in relation to which transaction or amount. If the wording is ambiguous, clarify it in the same ticket before you collect anything, not after you submit.
The practical difference is in the material. SoF needs the chain behind one amount: income, accumulation, conversion, transfer. SoW needs the structure of your capital: assets, business holdings, property, years of income history. The second package is far heavier, and there is no reason to build it speculatively.
When the question comes: the usual triggers
The request is rarely random. There is almost always an event behind it, and knowing the event tells you what actually needs proving.
- Enhanced due diligence after a profile change. Volumes went up, a new login country appeared, the trading pattern shifted.
- A large withdrawal or a large one-off deposit that does not fit your previous history.
- P2P turnover. Many counterparties, many small card payments, heavy inbound flow from individuals. The mechanics of that risk are covered separately in why banks block cards after P2P.
- A counterparty complaint or inbound flow from a flagged address. Here SoF sits on top of a question about one specific transaction.
- Relocation and a new bank. A European bank seeing an incoming transfer from a crypto exchange will almost always ask about origin. That is procedure, not suspicion.
- Scheduled re-verification or a KYC refresh, often paired with video verification.
- A tax enquiry. Formally a different process, but the underlying evidence is the same.
The best time to build the file is before anyone asks for it. If a large withdrawal is coming, prepare in advance: the procedure is in how to withdraw a large amount without triggering a flag.
What actually counts as evidence, by income type
The governing principle of serious review is corroboration. Every claim rests on an independent document, and the documents have to support each other rather than contradict each other. A tax return showing annual income below the volume of crypto you bought does not strengthen the file, it destroys it.
| Income type | Usually accepted | Typical mistake |
|---|---|---|
| Salary, freelance | Employer letter or income certificate, employment contract, account statement covering the pay periods, tax records | Submitting a statement full of credits with nothing explaining who paid them and for what |
| Business income | Registration documents, tax filings, business account statement, contracts with key clients | Personal and business flows mixed on one account, so the amount cannot be separated |
| Sale of property or a vehicle | Sale contract, proof of title transfer, credit of the proceeds to your account | The contract exists but the money never touched a bank, so there is no trace to follow |
| Investments, trading | Broker statement or an export of exchange trade history, a profit and loss reconstruction, proof of the initial deposit | Showing the profit only, with nothing on where the starting capital came from |
| Inheritance, gift | Grant of probate or notarised deed of gift, proof of receipt | A family arrangement agreed verbally, with no document behind it |
| Mining | Hardware invoices, electricity bills, pool agreement, payout history to your address | The declared output does not reconcile with the hardware capacity or the electricity bills |
| P2P trading | Order history export with confirmations, bank statements for both sides of the flow, a turnover and margin reconstruction | Order screenshots with no bank confirmation. This is the weakest common form of evidence |
A mixed source is normal and by far the most frequent situation. Do not force it into one tidy story: break the amount into components and give each one an amount, a period and a document. Three corroborated components beat one uncorroborated narrative every time.
The weakest point in almost every file: fiat to crypto
Nine out of ten weak packages I have reviewed broke at the same place. The person carefully proves where the money came from and says nothing about how the money became crypto. The institution sees documented income and sees crypto assets, but no bridge between them. That gap produces exactly the question you were trying to avoid.
The bridge is built out of chronology and transaction identifiers. The minimum chain looks like this:
- Income. Date, amount, supporting document, credit to the account.
- Accumulation. An account statement for the period showing the money actually sat there.
- Conversion. Transfer from your account to a verified exchange account or a licensed broker, with date and amount, followed by the purchase order in the exchange history.
- Exit on chain. The withdrawal transaction from the exchange to your address, with its hash (TxID). This is the link that is almost always missing.
- Current position. The address, the balance, and an independent screening of that address.
The TxID does the job that a payment order does on paper: it makes a claim checkable. "I bought crypto on an exchange with my own money" offers nothing to verify. "On 12 Aug 2025, USD 9,000 was transferred from my account at Bank X to my verified account at Exchange Y, USDT was purchased the same day and withdrawn to address TX... in transaction hash ..." can be verified in half a minute, which is precisely why it works.
One more thing about your own addresses. Screen them before you submit, because if there is a problem in your inbound flow you want to be the one who finds it. Our free checker shows the Tether blacklist, sanctions matches and the basic behavioural patterns of an address. A clean result goes into the package as evidence in its own right. A finding is not hidden, it is disclosed by you along with the circumstances of receipt: the institution will see it anyway, and once something looks concealed the whole file is in doubt.
Format matters more than people expect
This is where files fail for no good reason. The three most common technical rejections:
A screenshot instead of a digital document. A bank statement is accepted as a digital PDF exported from the bank, with all its identifiers intact. Photos of a screen, cropped images and "the part of the statement where you can see the payment" get rejected. Binance states in its own help material that it accepts a digital three-month PDF statement and rejects photos and cropped documents. In practice the same rule applies almost everywhere, including where nobody wrote it down.
Stale documents. Many institutions accept documents no older than three months, and OKX publishes exactly that requirement. A statement from a year ago proves nothing about the present.
Language. International exchanges handle EDD centrally. The fact that support replies to you in your own language does not mean the reviewer reads it: a localised support template and the language of review are two different things. A package for an international exchange or an issuer is assembled in English, with translations attached for the key documents. A local institution, a bank or a tax authority, receives documents in its own language. Filing with a European bank often means a sworn translation, and notarised documents may need an apostille. Confirm the specific requirements with a lawyer in the country you are filing in.
And the fourth, most expensive one: the deadline. Submission windows are hard and inconsistent. Per the exchanges' public help material, Bybit allows roughly 72 hours to submit documents during withdrawal verification before the request closes automatically, Bitget works to roughly 18 calendar days for EDD, and MEXC states up to 30 days for AML review although documented cases have run far longer. Re-check these windows at the moment you file, because they change. There is a dedicated breakdown in exchange submission windows and deadlines.
The statement itself: seven blocks
The statement is not a free-form letter and not a folder of files. It is a short signed document plus ordered evidence, where every claim in the text has a matching exhibit.
- Header. Date, full name, citizenship and residency, account or case identifier. A document with no account identifier gets lost immediately, because there is nothing to attach it to.
- Subject. One sentence: which amount, which asset and which institution this concerns.
- Origin of funds. The core of the document. A story with no gaps, and where the source is mixed, a breakdown by component with amounts, periods and the name of each supporting document.
- The fiat to crypto link. Dates, amounts, institution names, TxIDs.
- Current position. Where the funds are now, on which address or account.
- Statement of legitimacy. Short: the funds were lawfully obtained, you are the beneficial owner, you have no knowledge of any link to illicit activity, and you will provide further documents on request.
- Schedule of evidence and signature. A numbered list of exhibits, each one tied to a specific claim from blocks three and four.
Three pairs of wordings where files usually lose their weight.
| Block | Strong wording | Weak wording |
|---|---|---|
| Subject | "This statement concerns funds of approximately 42,000 USDT on the TRON network held in account ID 1234567." | "I am writing about my funds which you have blocked." |
| Origin | "The funds derive from two sources. Salary income from March 2023 to December 2025, approximately USD 31,000 in total, evidenced by an employer income certificate and account statements. Sale of a vehicle on 18 July 2025 for USD 12,500, evidenced by the sale contract and the credit to my account." | "These are my personal savings that I built up over many years by working and selling various things." |
| Legitimacy | "I am the beneficial owner of these funds. I have no knowledge of any connection between them and illicit activity. I am willing to provide additional documentation on request." | "I guarantee that all my funds are completely clean and there can be no claims against me." |
The failure mechanism is identical in all three weak versions: they give the reviewer nothing to anchor on. The weak subject line also sets a combative tone with the word "blocked", when the document should read as neutral. The weak legitimacy line asserts something you cannot possibly know about every prior holder of the coins, and that costs you credibility for the rest of the text.
Things never to write: judgements about the institution's conduct, threats of litigation or regulatory complaint in a first document, guarantees, any figure that differs from your statements even by a unit, emotion and personal circumstances, and speculation about why you are being reviewed. A skeleton you can copy is in our open Source of Funds template, and the situation itself is covered on the source of funds request page.
Mistakes that kill a file
- Assembling the wrong thing. SoW instead of SoF or the other way round. Weeks lost, the review queue restarted.
- Submitting in pieces. Every extra file sent afterwards restarts the review in most processes. One complete package, once.
- Ticket spam. Parallel requests through several channels do not speed anything up. They lower your priority and mark you as a difficult customer.
- Amounts that do not reconcile. Documented income below the volume of crypto purchased. That arithmetic is done quickly and mechanically.
- Changing your version of events. The fastest way to destroy trust in the entire package. If your first answer was imprecise, correct it explicitly and explain the correction rather than quietly rewriting the story.
- Missing the deadline. Some processes close automatically, and reopening them is harder than making the window.
- Filing with no forensics when the inbound flow is contaminated. If there is a problem in your addresses and you submit paperwork alone, you are effectively asking the institution to find it for you.
- Fabricating a document. That is a criminal offence and the fastest route from "customer with questions" to "suspicious person". We do not take those cases at all.
Jurisdictional notes
Ukraine. Banks actively ask for an explanation of source after P2P activity and work to their own financial monitoring timelines. In practice a clean package, meaning statements plus income documents plus order history, closes the question in days rather than months. Keep the tax side in mind separately: an updated regime for taxing virtual asset transactions applies from 2026, and the details are worth confirming with a tax adviser rather than inferring from forums.
Kazakhstan. The classic case is a Kaspi or Halyk card block after P2P with a request for explanations. The key local point: exchanging through licensed venues leaves a documented trail and materially strengthens your position, while activity outside the licensed perimeter is treated as high risk by default. Complaints about a financial institution's conduct go to the financial regulator, not to the financial intelligence unit, which are different bodies with different remits. Confirm the timelines and grounds with a local lawyer.
Relocation to the EU. A European bank seeing an incoming transfer from a crypto exchange will typically hold it and ask for documented origin. Germany is among the strictest. Documents issued outside the EU almost always need translation, and notarised ones may need legalisation. The point people forget: if you refreshed your exchange KYC with a European address, the exchange now treats you as an EU resident with all the consequences, whatever passport you hold. The legal detail differs by country, and this is exactly the situation where an hour with a local lawyer is worth the money.
Pre-submission checklist
- The request is recorded verbatim: SoF, SoW or both, for which period and which amount.
- A one-page money chronology exists before any documents are collected.
- Every link in that chronology has a document you can open right now.
- Amounts reconcile: documented inflows cover the volume converted.
- Dates are logical: the crypto purchase does not precede the income that paid for it.
- The fiat to crypto link is closed with a transfer, an order and a TxID.
- Your own addresses are screened, a clean result is attached, any finding is disclosed by you.
- Format: digital PDFs, documents within the institution's freshness requirement, language matched to the recipient.
- The statement and the exhibits do not contradict each other on a single figure or date.
- The text contains no guarantees, no judgements about the institution, and no emotion.
- The package is filed once, through the correct channel, before the deadline, with proof of submission saved.
The honest limit
A file does not guarantee an outcome. The decision belongs to the institution's compliance function, and nobody promising you a guaranteed result has any basis for that promise. What a file does do is remove the grounds for questions and move your case from "unclear" to "verified". In our experience, documentable income plus paperwork produces materially better odds than undocumented income with no trail. If there is nothing to corroborate, I will say so plainly instead of selling hope: fabrication is off the table, and sometimes the most useful advice is to build a lawful trail going forward rather than to prove the unprovable after the fact.
If you want to learn to build these packages yourself and work cases through the full procedure, that is the backbone of the Onyx Academy programme. If the request has already landed and a clock is running, describe it in our free case assessment: we will tell you what to collect in your specific situation, and we will tell you honestly if the odds are poor.