Risk Disclosure

Version dated 23 October 2026

IMPORTANT: YOU MAY LOSE SOME OR ALL OF THE FUNDS OR DIGITAL ASSETS INVOLVED IN AN AFFECTED TRANSACTION. ACCESS MAY BE SUSPENDED, DELAYED INDEFINITELY OR LOST PERMANENTLY. Losses may arise from bank or provider insolvency, fraud, cyber incidents, settlement failures, stablecoin depegging, issuer restrictions, errors, regulatory action or other events described below. Exposure can substantially exceed the transaction fee. A stablecoin, named account, local payment route or BloxFi-branded interface does not make a transaction risk-free.

BloxFi does not insure your funds or guarantee a risk-free outcome, continuous access, recovery, a stablecoin's value or the solvency of an independent provider. Responsibility for a loss is determined by applicable law and the governing agreement. This disclosure preserves valid contractual exclusions, liability caps and client indemnities; it does not exclude liability that cannot lawfully be excluded or relieve a contracting entity of obligations it has expressly accepted.

Read this disclosure before onboarding, funding an account, giving authority to act, accepting a quote or initiating a transaction. If the service, fund holder, legal counterparty, permitted use or risk allocation is unclear, obtain clarification before proceeding. Do not commit funds needed for a critical deadline without an appropriate contingency plan.

1. Scope and contractual status

1.1 Services covered. This disclosure concerns approved local collections, local and international payouts, cross-border payments, currency conversion, fiat-to-digital-asset and digital-asset-to-fiat conversion, settlement, named and virtual account arrangements, approved provider balances, batch payments, payroll-related flows, APIs, dashboards, white-label interfaces, manual or assisted instructions, introductions and authorised automation. A risk applies only where the corresponding activity or exposure exists. Its description does not mean that the service is offered to you or in every market.

1.2 Meaning of BloxFi. BloxFi is a brand used for the arrangements described in section 2. References to BloxFi, we, us or our mean the entity responsible for the particular service or communication, not all entities jointly. An external bank, payment institution, liquidity provider, digital-asset issuer, exchange, custodian or other intermediary is referred to as a provider. You includes the business client and, where relevant, its authorised users. Underlying customers are persons for whom an approved client acts.

1.3 Governing documents. The applicable master service agreement (MSA), validly accepted product terms, transaction confirmation, authority mandate, Terms of Use and Acceptable Use Policy govern the relationship in their agreed order of precedence. This disclosure supplements them. It does not retrospectively vary an accepted transaction, substitute a different contracting entity, introduce an undisclosed provider contract, change ownership of funds or enlarge authority over assets. An existing agreement's amendment requirements remain applicable.

1.4 No additional products or authority. Nothing here authorises deposit-taking, lending, staking, yield generation, derivatives, margin trading, securities dealing, discretionary investment, rehypothecation or ongoing custody. Any such activity would require separate lawful approval and appropriate terms. Holding assets briefly for a permitted settlement purpose can nevertheless create custody, insolvency and access risks. Authority to execute a payment is not authority to invest, lend or pledge the funds.

2. Entity-specific roles and exposure

2.1 Victus Ventures GmbH. Victus Ventures GmbH, CHE-264.484.653, Dammstrasse 16, 6300 Zug, Switzerland, provides approved services under its Swiss agreement and Swiss self-regulatory organisation (SRO) anti-money-laundering framework. Depending on the activated service, it may be in the flow of funds and may receive, control, convert or arrange the onward settlement of money or digital assets. Its responsibilities follow the actual transaction, its agreement and applicable law. Swiss SRO affiliation is not a banking licence, deposit guarantee, approval of every activity or permission to operate in every jurisdiction.

2.2 BLOXFI LIMITED. BLOXFI LIMITED, Hong Kong company number 79037373, at Room 602, 6/F, Kai Yue Commercial Building, No. 2C, Argyle Street, Mongkok, Kowloon, Hong Kong, is the technology and administrative connectivity entity. It is not a licensed financial-services entity. Under its technology-service model, it does not receive, hold or control transaction principal; the approved client or underlying customer contracts with the identified financial provider for the financial service. Supplying an interface, introduction or administrative assistance does not make BLOXFI LIMITED a bank or payment principal. The actual activities performed and mandatory law remain relevant.

2.3 BloxFi Payments Inc. BloxFi Payments Inc., 5307 Victoria Drive #1325, Vancouver, BC V5P 3V6, Canada, has an ongoing Canadian money services business registration process. Pending registration must not be presented as completed registration, a licence, regulatory endorsement or permission to launch a service requiring additional approvals. Access through another approved entity does not activate Canadian services.

2.4 BloxFi USA LLC. BloxFi USA LLC has an ongoing US money services business registration process. A pending application is not an authorisation. FinCEN registration, if completed, would not by itself establish state money-transmitter licensing, deposit insurance or permission for every US activity. This disclosure does not confirm any state licence or activate a US service.

2.5 BloxFi Holding Ltd. BloxFi Holding Ltd., British Virgin Islands company number 2210802, is a non-operational holding vehicle. It is not the customer payment provider, custodian or transaction principal and does not guarantee another entity's obligations merely because the BloxFi brand is used. Victus Ventures GmbH is a separate Swiss company and is not represented here as a subsidiary of that holding company.

2.6 Identify your recourse. A common brand, website, employee contact, shareholder, referral relationship or technical interface does not create joint liability or a cross-entity guarantee. Identify the entity that owes each obligation and the provider that holds funds at each stage. Statutory liability, actual conduct and any express written guarantee remain unaffected. Changes to entity roles or permissions require proper disclosure and any necessary contractual approval before they affect your service.

3. Regulatory protection, safeguarding and insurance

3.1 Different protections. Payments, foreign exchange, digital-asset services, e-money, technology services and bank deposits are different legal arrangements. A registration, SRO affiliation, provider licence or compliance check does not establish that the whole transaction has been approved by a regulator. The protections depend on the entity, activity, customer classification, location, asset and applicable regime. A business client may have fewer protections than a consumer.

3.2 No automatic insurance. Do not assume that an account or balance is covered by deposit insurance, an investor-compensation scheme, a government guarantee, an ombudsman scheme or BloxFi's insurance. A provider's own insured bank account does not necessarily give each underlying customer equivalent protection. Eligibility, ownership, pass-through conditions, aggregate limits, exclusions and claims procedures may apply. Digital assets are not bank deposits merely because their issuer holds reserves at a bank.

3.3 Safeguarding is not a guarantee. Where safeguarding, trust, segregation or bankruptcy-separation rules apply, they may reduce particular risks but may not eliminate operational delays, reconciliation disputes, fraud, a safeguarding-bank failure, administration costs or shortfalls. Do not assume that arrangements under one entity or jurisdiction apply to another. This disclosure neither represents that all balances are safeguarded nor removes any safeguarding, segregation, accounting or return obligation imposed by law or contract.

3.4 Due diligence has limits. Provider reviews, identity checks, audits, screening, security certifications and risk scores are assessments at a point in time. They cannot establish that a provider is solvent, an asset is safe, a payment is lawful or a counterparty will perform. An insurer may reject a claim or have insufficient limits. BloxFi does not promise to compensate a client from its own insurance unless expressly required by the governing agreement or law.

4. Prohibited countries and territories

4.1 Contractual prohibition list. The following are the Red-Zoned Jurisdictions stated in the current BloxFi Acceptable Use Policy and Swiss and Hong Kong MSAs. This is BloxFi's contractual restriction list, not a statement that every location is subject to the same international sanctions or that every person of a particular nationality is prohibited.

4.2 Scope of the prohibition. The services must not be used by or for a client, underlying client, originator or beneficiary incorporated, registered, resident, located or operating from a listed jurisdiction, or for a transaction originating from, routed through or destined for one, including source, intermediary and destination accounts there. Both the Democratic Republic of the Congo and the Republic of the Congo are included. Crimea, Donetsk, Kherson, Luhansk and Zaporizhzhia are separately listed territories or regions; their inclusion does not express a view on sovereignty. The contractual regional names are not narrowed here to only particular occupied areas.

4.3 No implied permission elsewhere. Omission from this list does not mean that a country, person, business, currency, token, bank or payment flow is supported. Additional restrictions may apply because of law, sanctions, ownership or control, provider requirements, product eligibility, local permissions or risk assessment. A permitted country does not make every activity in that country permissible. Nationality alone is not substituted here for the location and other tests in the governing documents; separate legally applicable nationality restrictions may still require assessment.

4.4 Changes and urgent restrictions. Changes to contractual lists must follow the applicable agreement's amendment process. New or changed legal prohibitions apply when legally effective, and urgent risk restrictions or suspensions may be imposed to the extent permitted by law and the existing agreement. A historic approval, quote, successful transaction, cached list or unblocked dashboard does not override a current legal restriction. Obtain confirmation for any uncertain country, territory, account or route before funding.

5. Sanctions, financial crime and compliance holds

5.1 Sanctions are wider than countries. Applicable sanctions and export-control rules may restrict named persons, entities they own or control, sectors, services, goods, currencies, wallets, vessels or particular transactions. Different regimes, including those of Switzerland, the United Nations, the UK, the EU and the US, can apply through different parties or transaction links. Their designation, ownership, control and territorial rules differ. A list-name match is not the only basis for a restriction, and screening software is not a legal clearance.

5.2 Risk-based review. Politically exposed person status, a higher-risk jurisdiction, an unusual business or exposure to a monitored country may require assessment rather than an automatic legal prohibition. FATF monitoring categories are not interchangeable with BloxFi's contractual ban list or a worldwide embargo. BloxFi and providers may impose stricter eligibility requirements where permitted. Such requirements do not mean the client has committed misconduct.

5.3 Information and monitoring. Transactions can require identification of the client, beneficial owners, controllers, originators, beneficiaries, underlying customers, source of funds, source of wealth, purpose, invoices, wallet control and relevant licences. Travel Rule and other information-transfer obligations may apply. Review can occur before or after funding or execution and can be repeated after an approval. Missing, inconsistent, outdated or misleading information may lead to rejection, restriction, reporting or termination.

5.4 Blocking and non-disclosure. Money or assets may be blocked, frozen, segregated, rejected, returned, withheld from onward transfer or delivered to authorities when lawfully required. A regulator, court, bank, issuer or law-enforcement agency may prevent action or disclosure. Tipping-off and confidentiality rules can limit the reasons given and the expected release date. A support escalation does not remove a legal hold, and release or refund may be impossible while it continues.

5.5 No circumvention or forfeiture by implication. Do not conceal a beneficial owner, split transactions to avoid controls, use false addresses, change payment descriptions, use a VPN to disguise a restricted location, route through nominees or substitute wallets to evade a restriction. Exposure to suspicious or sanctioned assets can affect apparently unrelated balances. Compliance review is not an automatic contractual forfeiture of your assets; any confiscation, deduction or transfer must have a lawful basis.

6. UK services, GBP rails, FinProm and reverse solicitation

6.1 No UK licence representation. As at the date of this disclosure, none of the five entities identified in section 2 holds a UK financial-services licence or authorisation. This disclosure does not confer or evidence FCA authorisation, FCA cryptoasset registration, appointed-representative status or permission to approve financial promotions. Approved UK collection or payout legs use identified local collection and payout partners within their applicable permissions. Their status does not license BloxFi or the client for a separate activity.

6.2 GBP is not the legal test. Using a GBP account, UK sort code, UK payment rail or UK provider does not determine whether a service or promotion is lawful. UK rules may be relevant to communications or activities directed at, received by or having an effect on persons in the UK, even where the business, website, staff or contracting entity is overseas. Conversely, a GBP transaction does not by itself establish that every element is a regulated cryptoasset promotion.

6.3 Your own permissions and promotions. You remain solely responsible for your own business's required permissions, registrations, lawful exemptions and financial promotions, including those of your agents, affiliates, introducers, distributors and white-label channels acting for you. You must establish and maintain the applicable legal basis at your own cost, obtain any necessary approval and comply with its exact scope, audience, content, risk-warning, recordkeeping and other conditions. This includes the UK Financial Services and Markets Act 2000 financial-promotion restriction, applicable Financial Promotion Order exemptions and relevant FCA rules, to the extent they apply to your activities.

6.4 No borrowed approval. A provider's approved widget, account details, branding, onboarding checks or compliant operations do not automatically approve your website, social media, emails, referrals, surrounding content or onward service. General BloxFi onboarding approval or a salesperson's operational confirmation is not legal advice, a financial-promotion approval or a UK legal opinion. Service permissions and promotion permissions must each be assessed. A promotion must stop or be corrected if its approval is withdrawn, its conditions cease to apply or its audience or content changes materially.

6.5 Reverse solicitation. An unsolicited approach is a factual circumstance requiring a case-specific legal assessment; it is not a universal licensing or FinProm exemption. An online tick-box, standard contractual statement or customer request does not retrospectively cure earlier solicitation or automatically authorise onward marketing, new products or dealings with underlying UK customers. Any reliance must be legally available, truthful and supported by contemporaneous records of how the relationship actually arose. Do not manufacture, backdate or preselect evidence, or describe a solicited relationship as unsolicited.

6.6 Evidence, suspension and allocation. Where the Terms of Use require prior written operational approval for UK-connected use, obtain it before activation; it is separate from regulatory permission. BloxFi may require evidence of permissions, specific promotional approvals, audience controls and a suitably scoped legal assessment where permitted by the governing agreement, without requiring the waiver of legal privilege. Unapproved UK-facing activity may be stopped, restricted, removed or declined. Consequences of a breach may include regulatory action, criminal or civil proceedings, restitution claims, unenforceability, frozen flows and loss of business. The client indemnities and exclusions in the governing agreements apply to the extent valid and applicable. Each BloxFi entity remains responsible for its own non-transferable legal duties; this disclosure is not a waiver of them or proof that a UK partnership agreement has been executed.

7. Ownership, balances and account structures

7.1 Identify the legal arrangement. An amount displayed in a dashboard may represent a provider balance, a reconciliation entry, a pending receipt, a claim against a particular entity or assets held under a separate arrangement. It is not necessarily cleared cash, a bank deposit in your name, beneficial ownership of particular tokens or immediately withdrawable money. Understand who receives the money, in whose name the account is held, who owes the onward obligation and when each claim arises.

7.2 Named, virtual and pooled accounts. A named account or virtual IBAN may be an identifier assigned within a provider's wider banking structure rather than a separate bank account legally owned by you. Pooled or omnibus arrangements combine receipts operationally and rely on accurate subledgers to allocate entitlements. Naming, reference codes and account numbers alone do not establish trust status, segregation, deposit insurance, direct rights against a bank or protection from every creditor.

7.3 Reconciliation and access. Incorrect references, payer-name mismatches, missing customer information, delayed statements, duplicate messages, ledger defects or competing claims may prevent allocation or access. A provisional credit may be reversed following reconciliation. An apparent balance discrepancy must be reported promptly. Display errors do not create ownership of funds that are not yours, and a balance correction must reflect the actual contractual and legal position.

7.4 Limited use of account details. Collection details may be limited to particular currencies, countries, senders, first-party or approved third-party flows and specified purposes. They may not support cash deposits, cheques, card settlements, direct debits, interest, overdrafts or every local rail. Account details can change or be withdrawn. Choosing a named account or an alternative bank route remains subject to availability, approved use and provider terms; there is no unconditional right to every route shown.

8. Bank, provider and insolvency risk

8.1 Chain of counterparties. A transaction can involve several banks, payment institutions, correspondents, FX dealers, issuers, exchanges, custodians and settlement agents. Any may fail, default, lose permission, close accounts, restrict an asset, refuse a transfer or become unable to perform. The failure of one provider can affect several routes at once, including providers that depend on the same bank, cloud system, issuer or liquidity source.

8.2 Recovery and priority. Insolvency can cause a moratorium, account freeze, administration, resolution, disputed ownership, set-off claims, netting, restructuring or a distribution below the expected amount. Lawfully applicable provider liens, security interests or bank-resolution write-downs or conversion of eligible claims may affect recovery. Depending on the actual arrangement and law, a claimant may have proprietary, safeguarded, trust, secured, priority or unsecured rights. Rights may be difficult to prove if records are incomplete or assets are commingled. This warning does not authorise pledging client assets. Protection and recovery priority depend on the actual arrangement.

8.3 Foreign proceedings. Recovery may require proceedings in another country, recognition of an insolvency process, translations, local advisers and proof of beneficial ownership. Conflicting laws, capital controls, sanctions, recovery expenses and delays can reduce or prevent recovery even where a legal claim exists. You may have no direct contract with a downstream provider and may need to pursue the entity that owes you the relevant obligation.

8.4 Limits of a provider disclaimer. BloxFi does not guarantee an independent provider's solvency or promise to make good every provider failure. Equally, a provider relationship does not automatically remove the contracting BloxFi entity's agreed execution obligation or mandatory duties concerning provider selection, oversight, custody, safeguarding or return. The governing agreement and law determine which party bears an actual provider-related loss.

9. Custody, wallets and private keys

9.1 Control determines exposure. Digital assets may be held in a wallet controlled by you, the contracting BloxFi entity where authorised under the applicable service agreement, an approved provider or another identified person for an authorised purpose. Hot wallets, cold storage, multi-signature wallets and multi-party computation have different risks. No technique eliminates loss, insider misuse, access failure or recovery limitations. Technical control of a private key and legal ownership of an asset are not necessarily the same.

9.2 Keys and access. Loss, theft, corruption or disclosure of private keys, seed phrases, signing shares, authentication devices, recovery credentials or backup material can cause permanent loss. A provider may be unable to recover self-custodied assets. Quorum failures, unavailable signers, employee departure, device damage or compromised recovery procedures can prevent an otherwise legitimate transfer. Key rotation or a change of authorised personnel must be completed through the agreed controls.

9.3 Custody dependencies. Provider-controlled wallets may depend on subcustodians, hardware vendors, software libraries and operational approval processes. Maintenance, insolvency, legal holds, fraud alerts or a security incident may delay access. A custody arrangement or transaction mandate does not authorise lending, rehypothecation or use for the custodian's own account unless lawfully and expressly agreed separately. Legal segregation and asset-return obligations are not waived by accepting wallet risk.

10. Stablecoin, issuer and redemption risk

10.1 Loss of value. A stablecoin, including USDC or USDT where supported, may trade below or above its reference currency, lose its peg or become worthless. Reserve losses, illiquidity, bank failures, issuer insolvency, fraud, operational failure, legal restrictions or a loss of market confidence can affect price and redemption. A reference to one dollar or another currency is not a guarantee that you can sell or redeem at that amount when needed.

10.2 Reserve information. Published attestations, audits, reserve reports and redemption policies have particular scopes, dates, assumptions and limitations. They do not prove that reserves will remain sufficient or accessible, or that each holder has a direct proprietary claim over them. Rights depend on the token, issuer, contract, holder eligibility and applicable law, including any mandatory redemption or reserve protections.

10.3 Redemption and conversion. Direct issuer redemption may require eligibility, onboarding, minimum amounts, fees, approved banking access and compliance information, subject to any mandatory holder redemption rights. You may instead rely on a market intermediary. Redemptions or conversions can be delayed, restricted or unavailable, especially during stress or outside banking hours. A liquid trading market and issuer redemption are separate mechanisms; either can fail while the other remains available.

10.4 Issuer powers and supported assets. An issuer or token administrator may have powers to freeze or block addresses, pause transfers, upgrade contracts, change supported networks or take other actions under its terms or legal obligations. Tokens received from another person may later be affected by an investigation or blacklist. A ticker, logo or wallet display does not establish that a token is genuine or has the rights associated with the native asset.

10.5 Fiat payment obligations remain distinct. A provider's internal use of stablecoins does not by itself transfer ownership of those stablecoins, or all depegging and execution risk, to a client that contracted for a fiat payout. Delivery of a token to an intermediary does not automatically satisfy an obligation to deliver fiat to the recipient. The confirmed transaction and governing agreement determine the promised result and allocation of risk.

11. Blockchain execution and network failure

11.1 Irreversibility and finality. A blockchain transfer may be irreversible once submitted or confirmed. A transaction hash, explorer entry or initial confirmation does not necessarily establish sufficient finality, legal discharge or successful receipt by the intended party. Reorganisations, consensus attacks, conflicting transactions, validator failure or an exchange's confirmation policy can delay credit or reverse the apparent history of a transfer.

11.2 Wrong assets and destinations. An incorrect wallet address, network, token contract, memo, destination tag or routing instruction can cause permanent loss. Similar address formats or token names do not establish compatibility. Depositing an unsupported token, sending to a contract that cannot receive it, using a closed address or selecting an incompatible chain may make recovery impossible. A small successful test does not guarantee that a later transaction will succeed or be unrestricted.

11.3 Protocol and market infrastructure. Congestion, gas-price spikes, insufficient fee tokens, software bugs, chain halts, spam, censorship, validator or sequencer outages, denial-of-service attacks and changes in consensus can interrupt transfers. Cryptographic weaknesses, future technological advances or implementation defects may compromise security. Public transaction ordering can expose transactions to front-running, sandwich attacks or other value extraction where the relevant execution mechanism permits it.

11.4 Recovery limitations. Recovery may require the cooperation of a wallet controller, issuer, network participant, exchange or authority and may involve costs or disclosure of information. It is not guaranteed and may be technically or legally prohibited. BloxFi is not required by this disclosure to support an unsupported chain or perform a recovery operation that would compromise security or other clients' assets. Any recovery obligation and charge depend on law and the agreed service terms.

12. Smart contracts, bridges, forks and token changes

12.1 Additional dependencies. Where expressly supported, a smart contract, bridge, wrapper or interoperability protocol can introduce separate code, validator, oracle, custodian and governance risks. Vulnerabilities, incorrect oracle data, administrator-key compromise, malicious upgrades, faulty minting or burning, lost collateral and bridge exploits can cause complete loss. An audit does not eliminate these risks or guarantee that the deployed code is unchanged.

12.2 Native and bridged assets. A bridged or wrapped asset may be a claim on another party or protocol rather than a token directly issued by the named stablecoin issuer. It may depend on locked collateral and a functioning redemption or unwrapping mechanism. It may not carry the same issuer, reserve, redemption or insolvency rights as the native token even if it uses a similar name. Do not substitute one asset for another without approval.

12.3 Forks, migrations and benefits. A network fork, token migration, chain retirement or redenomination may create competing assets, inconsistent records or a need to move assets before a deadline. Providers may support only selected versions. Forked tokens, airdrops, rewards or voting rights are not automatically credited or exercised for you unless required by law or expressly included in the service. A purported airdrop or migration can itself be a scam.

13. Currency conversion, quotes and costs

13.1 Indicative and binding prices. A displayed or preliminary price may be indicative, stale or conditional. A firm quote may expire or depend on funding by a deadline, exact currency and amount, cleared receipt, transaction limits and compliance clearance. Accepted binding quotes remain governed by their agreed conditions; a general market-risk warning does not give BloxFi an unlimited right to reprice a fixed contractual obligation.

13.2 Price and liquidity changes. FX movements, spreads, market gaps, thin liquidity, capital controls, token depegging, exchange closures and provider withdrawal can affect executable prices. A market-based or otherwise variable-price instruction may experience slippage, partial execution or different prices across execution legs. A return or unwind may use a different rate from the original conversion and produce a smaller amount.

13.3 Total cost. Depending on the agreed route, costs may include disclosed service fees, FX spreads, provider charges, bank or intermediary deductions, network fees, applicable taxes and permitted recovery or return costs. A downstream bank may apply charges outside BloxFi's control. A quoted recipient amount or all-in fee must be treated according to its actual contractual terms; this disclosure does not authorise hidden charges or contradict an agreed guaranteed amount.

13.4 Unfunded commitments. Confirming a trade may create a binding obligation before all funding arrives. Late funding, a cancellation request or a rejected funding source may require an unwind or replacement transaction. Reasonable, documented losses or costs may be payable where the governing agreement validly allocates them to you. The disclosure does not introduce credit, leverage, a margin facility or an unlimited debt obligation.

14. Routing, liquidity and conflicts

14.1 Available routes only. Routing compares available and eligible options within the connected network, using information available at the relevant time. It does not necessarily cover every bank, exchange or market, or guarantee the lowest cost, fastest delivery, best available market price or uninterrupted liquidity. Contractual or mandatory best-execution duties, where applicable, remain unaffected.

14.2 Model and information limitations. A route can appear available but fail because a balance, limit, rate, provider status, compliance decision or local banking condition has changed. Quotes and estimated delivery times may use delayed, incomplete or incorrect data. Algorithms, matching logic and optimisation settings can misclassify a route. Historical reliability is not a promise of future performance.

14.3 Economic interests. BloxFi or an introducer may receive a spread, fee, commission or other agreed remuneration, and a provider may be affiliated or commercially preferred. These interests may differ from your objective of minimising cost or time. Material conflicts and remuneration must be handled and disclosed as required by the governing agreement and law. This warning is not consent to an undisclosed conflict or a route outside your authority.

14.4 Concentration and substitution. Several displayed options can rely on the same underlying bank, token issuer or infrastructure. A backup route may be unavailable during a shared disruption. A material change of asset, counterparty, funding instruction or risk exposure must follow the existing mandate and any required approval; a risk warning does not itself authorise an unrestricted reroute.

15. Timing, local rails and multi-leg settlement

15.1 Estimates and dependencies. Delivery depends on cleared funding, accurate instructions, provider availability, operating hours, holidays, time zones, cut-offs, recipient-bank processing, compliance checks and network conditions. References to instant, same-day or near-instant settlement are subject to the specific service conditions. Technical availability around the clock does not mean every banking, redemption or support function operates continuously.

15.2 A connected flow is not necessarily atomic. Collection, conversion, blockchain transfer and local payout are separate steps. One step may complete while another is delayed, rejected or fails permanently. Funds may remain temporarily in a different currency, asset or provider arrangement, or require an unwind, return or alternative instruction. The contract determines the exposure and completion point; an internal status change does not unilaterally redefine the promised recipient payment.

15.3 Local payout differences. A domestic rail can impose limits, account-type restrictions, name checks, purpose codes, recipient eligibility and availability windows. Recipient banks can reject or delay a credit or apply their own controls. A local payment route is not equivalent to a guarantee that the recipient has unrestricted access to funds or that no intermediary is involved.

15.4 Batch and time-critical payments. A payroll, supplier or customer batch may execute only partly. Retrying the whole batch before checking individual results can create duplicate payments. A delay can cause missed wages, supplier default, contractual penalties or commercial loss. Maintain sufficient time and alternative arrangements for critical obligations; any recoverable loss remains subject to the governing agreement and law.

16. Funding, prefunding and available balances

16.1 Funding instructions. Use only current, independently verified instructions for the approved transaction, currency, network and originating party. An old beneficiary, an email change or a third party's screenshot may be incorrect or fraudulent. Cash, cheques, unsupported assets, unexplained third-party deposits and transfers from unapproved sources may be rejected or held for investigation.

16.2 Cleared and available funds. A receipt notification is not necessarily cleared or final funding. Provisional credits, holds, reserves, pending withdrawals, unresolved fees or concurrent instructions can reduce the available amount. Spending against an unconfirmed balance may create a shortfall, failed transaction or debt to the extent provided in the agreement. Client-side calculations should not replace the provider's confirmed available-balance and transaction records.

16.3 Prefunding exposure. Funding ahead of execution increases the period during which funds may be exposed to bank, provider, operational or insolvency risk. A balance held for payment purposes is not necessarily a savings account or a long-term storage service, and interest is not promised unless expressly agreed. Keep funding and liquidity arrangements proportionate to approved payment needs and any service limits.

17. Reversals, recalls, chargebacks and returns

17.1 Different finality rules. A fiat receipt may be returned or challenged after a digital-asset transfer or payout has become irreversible. Fraud claims, unauthorised-payment disputes, chargebacks where applicable, insolvency clawbacks, legal orders and bank corrections may arise after an initial success message. This mismatch can create losses and liabilities beyond the original service fee.

17.2 No guaranteed recall. A cancellation or recall is a request, not proof of recovery. A recipient, bank, issuer or network may refuse or be unable to reverse a completed transfer. Sending a duplicate replacement before resolving the original creates additional exposure. A refund may require verification of the original source and may be prohibited to a different person, wallet or jurisdiction.

17.3 Amount and timing of a return. A lawful return can be delayed by investigations, beneficiary cooperation, banking hours, conversion requirements and legal holds. The returned amount may differ because of permitted deductions, market movements and already-incurred charges. Any fixed refund obligation or unauthorised-payment remedy under law or contract remains applicable; this notice does not replace it with an unrestricted discretion.

17.4 Claims and recovery allocation. You may be required under the governing agreement to repay a provisional credit, reimburse an attributable reversal or provide supporting records. Such obligations are not automatically established merely because a third party alleges fraud. Rights to debit, set off, retain or recover funds must have a valid contractual or legal basis and respect restrictions protecting customer assets.

18. Payment details and beneficiary errors

18.1 Unique identifiers. Banks and payment systems may execute using an account number, IBAN, wallet address or other unique identifier even where a displayed name is incomplete or inconsistent. Account-name checking is not available for every route and does not prove ownership, authority or commercial legitimacy. A valid-format identifier may still belong to the wrong person.

18.2 Instruction quality. Incorrect amount, currency, decimal precision, beneficiary, purpose code, country, intermediary detail or reference can cause misdirection, rejection, additional conversion or permanent loss. Transliteration, truncated characters and incompatible file formats can alter data. Reused beneficiary records must be reviewed when the recipient changes bank, legal name or location.

18.3 No guarantee of underlying entitlement. Payment confirmation establishes only the status supported by the relevant records. It does not verify that the beneficiary is entitled to the money, has performed a contract or is free of fraud. Responsibility for instruction errors and any verification undertaken by BloxFi remains governed by the accepted service terms and applicable law.

19. Third-party and underlying-customer flows

19.1 Express approval required. Authority to use a business account does not automatically permit undisclosed money transmission, nested payment services, collecting for unrelated merchants, sub-aggregation, nominee activity or holding funds for others. First-party and third-party flows must stay within the approved model. A master authorisation does not replace beneficial-owner disclosure, required licences or an underlying customer's valid authority.

19.2 Your customer obligations. Where you lawfully act for underlying customers, you remain responsible for your own customer contracts, permissions, records, disclosures, mandates, subledger accuracy, complaints and payment instructions. Screening by BloxFi or a provider does not automatically discharge your own due-diligence or monitoring obligations or establish permitted regulatory reliance. Each party retains the duties that apply to it.

19.3 Pooled balances and competing claims. An institutional or pooled arrangement can expose several customers to a hold, reconciliation problem or provider failure. Incorrect allocations, refunds to the wrong person, inconsistent customer ledgers or a client insolvency can prevent identification of beneficial interests. Approval of a customer record does not automatically create a direct account or service contract between that person and BloxFi or a downstream bank.

19.4 Lawful disclosures and information. Explain the actual service provider, permitted use, material risks and relevant limitations to underlying customers where required. Obtain lawful authority to send their information and instructions, and provide requested transaction data through approved channels. Do not represent that customer funds have protection, insurance, ownership rights or guaranteed availability that the actual arrangement does not provide.

20. Fraud, impersonation and social engineering

20.1 Fraud methods. Risks include phishing, fake apps and websites, invoice substitution, business-email compromise, cloned domains, compromised messaging accounts, fraudulent QR codes, address poisoning, malicious wallet approvals, SIM swaps, stolen devices and impersonation of staff, banks or counterparties. AI-generated voices, images, documents and video calls can make false instructions appear credible.

20.2 Authorised-push and insider fraud. A user may knowingly approve an instruction while being deceived about the recipient or purpose. Employees, contractors, controllers or counterparties may misuse access or collude. A genuine login or signature can therefore coexist with fraud, and an apparent authorised instruction may later be disputed. Allocation of loss is determined by the evidence, contract and applicable law, not solely by the presence of a credential.

20.3 Protective actions. Verify changed banking details using an established independent channel. Apply suitable dual approval, transaction limits, least-privilege access and separation of duties. Do not share passwords, private keys, seed phrases or one-time security codes with an introducer or support contact. Report suspected compromise immediately through a previously verified channel; delay can reduce the possibility of blocking or recovering a payment.

21. Manual instructions, delegation and communications

21.1 Assisted channels. Instructions given through an approved email, recorded call, messaging channel or settlement desk may be subject to authentication, cut-offs and confirmation procedures. Messages can be delayed, intercepted, altered, sent to the wrong person or misunderstood. An informal discussion, draft quote or unacknowledged message may not constitute an accepted transaction.

21.2 Authority and revocation. Keep authorised-user and signatory records current and promptly notify changes through the agreed procedure. Delegation can expose the client to instructions placed within an authorised person's actual or legally effective apparent authority. Revocation may not stop an instruction already accepted or irreversibly executed. Reliance on apparent authority and security checks remains subject to law and the governing contract.

21.3 Scope of a mandate. A permission to obtain quotes, introduce providers or transmit documents does not automatically authorise acceptance of every trade, movement of all funds, new beneficiaries or a change of risk exposure. Automated or delegated actions must stay within the approved mandate. Oral assurances or unofficial messages do not override a required written acceptance or contractual amendment process.

22. APIs, integrations and transaction records

22.1 Integration defects. Incorrect currency codes, decimal handling, rounding, time zones, authentication, permissions, beneficiary mapping or environment selection can create erroneous transactions. Duplicate retries, missing idempotency controls, race conditions and concurrent instructions may send the same payment more than once. A timeout can occur after an instruction has been accepted; check its status before resubmitting.

22.2 Messages and reconciliation. Webhooks, notifications and dashboards can be delayed, duplicated, delivered out of order or unavailable. A pending, submitted or successful technical response may describe only one stage. Reconcile against the authoritative transaction and settlement records under the service terms. Keep your own appropriately secured records and promptly report discrepancies; neither an interface nor your own ledger is infallible.

22.3 Dependency and change. APIs, SDKs, cloud platforms, open-source components and third-party integrations can contain vulnerabilities or change incompatibly. Rate limits, maintenance, version retirement, certificate expiry and dependency outages may interrupt service. Sandbox behaviour, test assets and sample code do not establish production readiness, actual settlement, regulatory approval or a service-level guarantee.

22.4 Your integration controls. Test material changes, implement appropriate retry and reconciliation logic, protect production credentials, separate environments and monitor access and error handling. Provider documentation does not substitute for your own implementation testing. BloxFi remains responsible for the technical obligations it actually undertakes; this disclosure is not a waiver for a defective service where liability cannot lawfully or contractually be excluded.

23. Cybersecurity, data and confidentiality

23.1 Security incidents. Malware, ransomware, distributed denial-of-service attacks, supply-chain compromise, privileged-access abuse, cloud outages, lost devices, domain or DNS compromise and physical intrusion may affect availability, confidentiality or integrity. Backups, encryption, access controls and monitoring reduce particular risks but do not eliminate every attack or restoration failure.

23.2 Data consequences. An incident can expose identity documents, banking details, transaction histories, credentials or commercially sensitive information, or corrupt payment records. Disclosure can enable further fraud, identity theft, competitive harm or legal claims. A service interruption may also affect reconciliation and incident reporting. Applicable security, breach-notification and data-protection responsibilities remain with the parties on whom the law imposes them.

23.3 Public ledgers and transfers of information. Blockchain addresses and transactions may be publicly visible, persistent and linkable to identities. Data sent to banks, providers, counterparties or authorities may cross borders and be subject to different legal access and retention rules. Information should be shared only as lawfully required or permitted for the approved purpose. Acknowledging these risks is not consent to unlawful processing or a waiver of privacy rights; the Privacy Policy and relevant data terms apply.

24. Automation, AI and experimental features

24.1 Automated decisions and actions. If approved automation is used, rules, algorithms or AI tools may rely on incomplete data, produce incorrect outputs, misinterpret instructions or respond to manipulated inputs. Prompt injection, compromised data sources or excessive permissions can cause unauthorised disclosures or actions. Automation must operate within the agreed authority, limits and human oversight requirements.

24.2 No professional advice by output. An automated explanation, route suggestion, support response or generated document is not a legal, tax, investment or regulatory opinion. It does not alter an accepted quote, approve a jurisdiction or extend a licence. Material errors should be escalated to an authorised human contact before funds are committed.

24.3 Trials and beta features. Features expressly identified as trial, preview, beta or sandbox may contain defects, change or be discontinued under their agreed terms. Test outputs do not evidence actual funds or production capability. Do not use live funds or critical production flows in a testing feature unless expressly permitted and appropriately controlled. No future feature, launch date or roadmap statement is a contractual commitment unless expressly agreed.

25. White-label, introductions and partner services

25.1 Brand and provider distinction. A white-label interface can display one brand while several entities perform different functions. A referral or introduction does not guarantee that the provider will accept the client, maintain a route or complete a transaction. It does not make the introducer a bank, payment provider, legal adviser or guarantor.

25.2 Commercial arrangements. Partners may earn revenue share, commissions or agreed margins. Their pricing, support and customer promises may differ from BloxFi's own obligations. Material remuneration and conflicts must be disclosed where required. An unauthorised partner statement does not extend a BloxFi entity's permission or commitment, subject always to applicable rules on authority, representations and responsibility.

25.3 Operational dependence. A partner outage, incorrect integration, insolvency, lost customer data or termination can interrupt access and customer communications. Customers may need to use another approved channel or migrate to a different arrangement. Underlying service contracts, data duties and funds-return obligations remain relevant even where the branded interface becomes unavailable.

26. Underlying business, advice and commercial loss

26.1 Payments do not validate a trade. Unless expressly agreed, BloxFi does not inspect goods, verify delivery, assure investment performance, provide escrow or resolve the commercial dispute underlying a payment. A supplier, employee, customer or investment counterparty may fail to perform, become insolvent or misrepresent its identity or entitlement. Completing a payment does not establish that the underlying activity is lawful or that the consideration is recoverable.

26.2 Independent decisions. You must assess your own business purpose, liquidity needs, recipient legitimacy and suitability of an approved service. Product information, market commentary, examples and introductions are not personalised legal, tax, accounting or investment advice. Past delivery times, historical rates, case studies and marketing illustrations do not guarantee future results or coverage.

26.3 Consequential exposure. An incident may cause lost profits, missed opportunities, reputational damage, lost customers, third-party penalties, financing costs or business interruption. Such losses are often excluded or limited under the governing agreement to the extent lawful. Do not assume BloxFi will reimburse every commercial consequence of using the service or that your own contractual commitments to customers bind BloxFi.

27. Legal change, market disruption and external events

27.1 Changing rules. Laws or regulatory interpretations concerning payments, cryptoassets, stablecoins, data, taxation, sanctions, promotions and customer assets can change. Authorities may reclassify an asset, restrict a route, require new approvals or order a service to stop. Continued support of a country, bank, currency, network, asset or business model is not guaranteed merely because it was previously approved.

27.2 External disruption. War, terrorism, civil unrest, natural disasters, epidemics, industrial action, power or telecommunications failure, banking holidays, exchange closures, capital controls and emergency government measures can interrupt payment and recovery. Several events may occur together. Alternative providers may be affected simultaneously, making contingency arrangements ineffective.

27.3 Legal and contractual treatment. Foreign courts or authorities may take a different view of contractual rights, ownership, digital-asset status, electronic evidence or an arbitration clause. Dispute resolution may be slow and costly. Whether an event excuses, suspends or terminates performance depends on the actual force-majeure clause, other contract terms and applicable law; this list does not automatically excuse every operational failure.

28. Tax, reporting and accounting

28.1 Potential obligations. Conversion, transfers, digital-asset disposals, fees, gains, losses and cross-border receipts may create tax, withholding, exchange-control or reporting obligations. Rules can differ between the client, beneficial owner, payer and recipient jurisdictions. Using a stablecoin or payment intermediary does not remove these obligations.

28.2 Records and valuation. Transaction histories and dashboard summaries may not be sufficient for statutory accounts, tax filings or proof of source of funds. Valuation dates, exchange rates, accounting classifications and tax treatment can differ from the platform display. Retain required records and obtain advice for your circumstances. BloxFi may be required to report information or apply lawful withholding; it does not guarantee a particular tax result or gross up a payment unless expressly agreed.

29. Suspension, closure, wind-down and recovery

29.1 Loss of access. Services or individual routes may be suspended or terminated under the agreement because of legal requirements, security incidents, missing information, misuse, unpaid obligations, provider decisions or other agreed grounds. A licence withdrawal, bank closure, provider exit or BloxFi entity insolvency may require a wind-down. Termination of access does not mean that all pending transactions can immediately be cancelled or returned.

29.2 Migration and return. An alternative provider may require new onboarding, permissions, account details, fees and customer communications. Pending transactions, inactive balances, residual tokens and minimum transfer amounts may complicate closure. Returns must use a lawful, verified destination and respect ownership, third-party claims and legal holds. No transfer to a different entity or service model is authorised merely by this disclosure.

29.3 Recovery limitations and costs. Tracing assets, pursuing a recipient, responding to an insolvency or implementing a technical recovery can be costly and unsuccessful. Reasonable recovery, conversion or administrative charges apply only where validly agreed or legally authorised. No guarantee of recovery, a particular timetable or a recovery amount is given. Non-recoverability does not itself extinguish a valid claim against a person responsible for the loss.

29.4 Dormancy and records. Dormancy, unclaimed-property rules, record-retention limits and loss of contact details can affect later access or recovery. Keep notices and contact details current, respond to verification requests and download records before closure where available. Funds must not be treated as forfeited merely because the account is inactive, except where a specific lawful rule requires their treatment in a particular way.

30. Client controls and incident response

30.1 Before transacting. Confirm the contracting entity, approved service, fund holder, route, asset, intended beneficiary, complete cost, funding deadline and expected settlement conditions. Understand whether you are dealing for your own account or for others and whether the selected account permits that flow. Provide accurate information and update material changes in ownership, activity, location, licences and customer model through the agreed process.

30.2 Operational resilience. Maintain appropriate access controls, segregation of duties, beneficiary verification, transaction limits, liquidity reserves, independent records, reconciliation and business-continuity arrangements. Avoid exposing all operational funds to one provider, wallet or time-critical transaction without an informed assessment. These precautions reduce risk but do not guarantee that a loss will be prevented.

30.3 Report promptly. Report a suspected error, unauthorised instruction, missing payment, compromised credential, data incident or prohibited transaction without undue delay using your authenticated dashboard or established support contact. Identify the client, transaction reference, time, amount, currency, route and relevant evidence. Provide wallet transaction hashes where applicable. Never send private keys, seed phrases, full passwords or authentication codes in a support request.

30.4 Preserve and contain. Preserve records, avoid duplicate payments, stop compromised credentials through a safe channel and follow lawful containment instructions. A support ticket is not a guarantee that an instruction can be stopped. Applicable notification periods and claims procedures remain those in the governing agreement and law; this disclosure does not create a new shorter limitation period or deem a late report conclusive proof of client fault.

31. Responsibility, exclusions and contractual protections

31.1 No insurance or universal undertaking. To the fullest extent permitted by applicable law and the governing agreement, BloxFi does not warrant that an approved service, route, currency or digital asset is free of risk, that independent third parties will perform, or that every loss will be prevented or recovered. BloxFi is not your insurer and does not assume your underlying commercial, market, tax or licensing obligations merely by facilitating a transaction.

31.2 Inherent and independently caused risks. Subject to that same limitation, no BloxFi entity assumes liability merely because an inherent market or digital-asset risk materialises, a client or independent third party causes an error, or an external event affects a transaction. Whether a BloxFi entity is responsible depends on its own role, the cause of the loss, the obligations it undertook and applicable law. Outsourcing an obligation does not automatically remove responsibility for it.

31.3 Existing liability limits preserved. All valid exclusions of loss categories, liability caps, causation requirements, mitigation rules, claims procedures and other protections in the controlling MSA or Terms of Use remain available. This disclosure does not increase a BloxFi entity's liability, create a new guarantee, substitute a different cap or impose joint liability on separate entities. It also does not convert an obligation to account for or return client property into a capped damages claim where the governing agreement or law treats it differently.

31.4 Client-caused losses and indemnities. Existing client payment, reimbursement and indemnity obligations remain applicable to the extent validly agreed, including those addressing unlawful activities, false information, lack of authority, sanctions or AML breaches, client promotions and FinProm non-compliance, misuse of services, third-party customer claims and losses attributable to client instructions. Any express uncapped indemnity in the governing agreement remains subject to its own wording and applicable law. This disclosure does not create a new unlimited indemnity or remove an expressly applicable contractual limit.

31.5 No automatic deduction or double recovery. A risk acknowledgement is not authority to seize client assets, impose undocumented charges, recover twice for the same loss or debit unrelated protected funds. Recovery of costs, legal expenses, fines or penalties must be permitted by the relevant agreement and law, attributable to the responsible party and subject to applicable claims-handling requirements. Fines and penalties are recoverable from another party only where legally permissible.

31.6 Mandatory and contractual limits. Nothing excludes or limits fraud, fraudulent misrepresentation, wilful misconduct, gross negligence, death or personal injury caused by negligence, or another liability, in each case to the extent that applicable law prohibits its exclusion or limitation. Nothing in this disclosure narrows any liability carve-out expressly preserved by the governing agreement. Mandatory duties concerning financial promotions, licensing, AML, sanctions, data protection, safeguarding, custody, unauthorised payments and return of assets remain applicable. A disclosure cannot legalise an otherwise unlawful service or replace controls required by law.

31.7 Non-exhaustive disclosure. Risks may interact, arise unexpectedly or change in ways that are not foreseeable when this document is issued. The examples are not exhaustive and are not ranked by probability or severity. Acceptance confirms awareness of disclosed risks; it does not establish that every undisclosed event was foreseen, that every loss is yours, or that BloxFi has complied with an obligation merely because the related risk was mentioned.

32. Acknowledgement, questions and updates

32.1 Informed acknowledgement. When this disclosure is presented for acceptance, you acknowledge that you have had an opportunity to read and retain it, understand the possibility of partial or total loss and prolonged loss of access, and are responsible for deciding whether an approved service fits your lawful business purpose and risk tolerance. The person acting for a business must have authority to give that acknowledgement. Do not confirm a fact that is untrue or proceed where a material uncertainty remains unresolved.

32.2 No blanket waiver. Acceptance is not a declaration that BloxFi never bears liability, a waiver of mandatory rights, an automatic agreement to undisclosed future terms, or proof of reverse solicitation, professional-client status, source of funds or regulatory permission. Any additional representation or authority must be obtained accurately through the appropriate onboarding or contractual process.

32.3 Questions and records. Ask questions through your authenticated dashboard, established BloxFi service contact or the contact details on the official BloxFi website. Independently verify any unexpected change in instructions. Keep the version you accepted together with the applicable agreement and transaction confirmations. Formal notices and complaints must follow the governing agreement's procedures.

32.4 Updates. This disclosure may be revised to explain changed services, risks, laws or restrictions. Publication alone does not retrospectively amend an existing MSA or completed transaction. Material contractual changes require the applicable notice, consent and amendment process. Mandatory legal restrictions and authorised urgent protective measures may apply sooner as described in section 4.4.