Financial Ombudsman Service decision

DRN-6308165

Unauthorised TransactionComplaint not upheld
Get your free defence insight →Email to a colleague
Get your free defence insight on the case against you →

The verbatim text of this Financial Ombudsman Service decision. Sourced directly from the FOS published decisions register. Consumer names are reduced to initials by FOS at point of publication. Not an AI summary, not a paraphrase — every word below is the original decision.

Full decision

The complaint Mr T complains about the way that FORISGFS UK Limited trading as Crypto.com (‘Crypto.com’) handled his claim for a refund. What happened Mr T has a Crypto.com account and his complaint is about transactions (the ‘transactions’) using his Crypto.com pre-paid Visa card. The transactions which were made over a few days in July 2025, were made using fiat currency – both sterling (around £3,350) and euro currency (around €1,206.57). Mr T was hospitalised during the period when he made the transactions and says that it came at a particularly vulnerable time for him. He says he has a problem with gambling and the businesses through which he was gambling, were unlicenced. Mr T contacted Crypto.com asking it to help him obtain a refund via the Visa chargeback scheme. Mr T’s main complaint is that the merchant names were misleading and didn’t reflect that they were, in fact, gambling websites. And he says Crypto.com didn’t do enough to protect him as a vulnerable consumer who had a gambling problem. Crypto.com declined to raise a chargeback. Amongst other things, Crypto.com said there wasn’t sufficient evidence to show the Visa ‘Merchant Category Code’ (the ‘merchant code’ or ‘MCC’) was incorrect. A MCC is a four-digit number assigned to businesses by the card networks, to classify the type of goods or services the relevant merchant (business) provides. So, as Mr T wasn’t claiming he didn’t receive the services he paid for and the MCC’s didn’t indicate the relevant merchants were registered as gambling businesses, Crypto.com said it couldn’t help him obtain a refund. Mr T disagreed with Crypto.com’s response and referred matters to us. Our investigator didn’t recommend upholding the complaint. Mr T asked for an ombudsman to review matters. I issued a provisional decision providing additional reasoning for not upholding this complaint. Crypto.com accepted my provisional findings. Mr T disagreed. Amongst other things, Mr T said: the pattern of payments over a short period of time should’ve flagged to Crypto.com that there was something wrong; he was misled as the companies he thought he was transacting with, hid their true identity; Mr T reiterated that he was at a vulnerable time in his life (medically) and Crypto.com should’ve done more to protect him. As Mr T disagreed with my provisional decision, I’m now issuing a final decision. What I’ve decided – and why I’ve considered all the available evidence and arguments to decide what’s fair and reasonable in the circumstances of this complaint. Having reconsidered everything, and whilst I know this will remain a disappointing outcome for Mr T, I’m still not upholding this complaint. Whilst I may not mention all of the submissions/arguments presented by both parties in this case, I’ve taken everything into account. No discourtesy is meant by this – it simply reflects our informal remit. In my provisional decision, which now forms part of my final decision, I explained why I wasn’t upholding this complaint. These reasons are as follows:

-- 1 of 3 --

Blocking gambling transactions due to Mr T’s vulnerability Mr T says Crypto.com should’ve done more to protect him as a vulnerable consumer including the fact he has a problem with gambling. From what I can see the first time Mr T raised this vulnerability along with his medical issues, was when he asked Crypto.com to raise chargebacks on his behalf which was after the transactions had been made. I appreciate Mr T made relatively large numbers of transactions within two days. However, in my view, this amount of spending, by itself, wouldn’t be enough for Crypto.com to fairly or reasonably know Mr T was actually gambling via these businesses. Crypto.com has confirmed its policy is not to allow any gambling transactions via its platform. Gambling blocks like this one, work by the financial business identifying the transactions via the merchant’s MCC. So, whilst this type of block can be useful, it is dependent on the gambling merchant having the correct MCC to identify itself, and, therefore, does have limitations. I asked Crypto.com to provide me with the MCC for each merchant who Mr T paid. The four merchants concerned had MCC’s under the following categories: Cosmetic Stores; Telecommunication Services; Information Retrieval Services; and Digital Goods - Audiovisual Media Including Books, Movies, and Music. So, the relevant MCC’s (i.e. merchant codes) assigned to all four merchants didn’t indicate the underlying business for each one was concerned with gambling. Crypto.com said while its systems automatically decline payments to recognised gambling MCC’s, it’s unable to pre-emptively block gambling platforms that operate under non-gambling codes. And in this case, the MCC’s used for each business didn’t flag the transactions as ones related to gambling. I realise it’ll be concerning to Mr T that these transactions were processed, but I haven’t found this is due to an error made by Crypto.com. Unfortunately, there are gambling websites that don’t use the correct MCC’s to circumvent these blocks. However, it wouldn’t be fair for me to hold Crypto.com responsible for the merchants being assigned the incorrect MCC. Finally on this point, I asked Crypto.com what it has done since finding out about Mr T’s vulnerability in respect of gambling. Crypto.com has told me it has now blocked the specific merchants involved to protect Mr T from further harm. I think Crypto.com is acting fairly here. But based on what information it had prior to Mr T flagging up his vulnerability and the websites he was using to gamble through, I can’t say Crypto.com acted unfairly in terms of those transactions that are the subject matter of this complaint. Chargebacks Moving on to Mr T’s chargeback requests, our Service would normally expect a financial business to raise one where there was a reasonable prospect of the dispute succeeding. When dealing with chargebacks, banks and providers of credit need to do so within the remit of the rules set by the relevant card scheme, who in this case is Visa. Crypto has told us it did check the nature of the problem raised by Mr T against the list of possible chargeback reason codes (rules). However, Crypto.com said Mr T’s request didn’t meet any of the chargeback scheme rules for raising a dispute. Reviewing Visa’s rules, it would appear that a gambling transaction would only be available under its chargeback scheme if the transaction were unauthorised and/or the service wasn’t received. Mr T confirmed that he made the payments and had been able to use the service. Therefore, I don’t think Crypto.com has acted unfairly here. Mr T thinks Crypto.com should’ve raised a chargeback for the relevant transactions under Visa’s ‘misrepresentation’ reason code. But Mr T wasn’t (and still isn’t) claiming he was misled about the nature of the transactions. Visa does have a reason code for invalid data (rule 12.7). Visa states that this code can be applied in situations where “…An authorization request contained an incorrect transaction date, MCC,

-- 2 of 3 --

merchant or transaction type indicator, Country or State Code, Special Condition Indicator, or other required field…”. However, as our investigator has said, there isn’t sufficient evidence to show that the incorrect code has been used. It should be remembered the merchant code itself isn’t assigned by the merchant – rather it is something that the relevant merchant acquirer’s (i.e. bank) decides based on the primary business of the merchant in question. And each merchant can offer a wide range of services, so, there may be a number of different codes that they can be identified with. And based on all the evidence it had available to it at the time, I don’t think Crypto.com acted unfairly or unreasonably when it declined to raise Mr T’s chargeback. This is because I don’t think his chargeback met the evidential requirements for the chargebacks to be successful. I’ve taken into account Mr T’s further submissions in response to my provisional decision. But I can’t see that he has added anything substantially new. For completeness, I’ll add the following: • I take on board what Mr T says about the amounts that were being paid over a short period of time. But this companies had merchant codes that weren’t related to gambling. So, I don’t think Crypto.com has acted unfairly here. • I’ve also reconsidered what Mr T said about being misled. I’m still not persuaded that this would’ve met the criteria for ‘misrepresentation’ under the Visa chargeback scheme as he knew what the transactions were being used for and did authorise these. • I appreciate what Mr T has said about his vulnerability and I’ve fully considered this. However, for the reasons I’ve set out above, I can’t say that Crypto.com acted unfairly in this regard. I don’t think there were any obvious triggers to show Mr T was gambling through the relevant websites and/or that he was vulnerable to this type of activity (gambling) until after he made the transactions. So, I can’t say that Crypto.com has acted unfairly here for not blocking the payments until after it became aware of these issues. For all these reasons, and whilst I very much sympathise with Mr T’s situation, my decision remains that I’m not upholding this complaint. My final decision My final decision is that I don’t uphold this complaint. Under the rules of the Financial Ombudsman Service, I’m required to ask Mr T to accept or reject my decision before 20 May 2026. Yolande Mcleod Ombudsman

-- 3 of 3 --