Consumer complaint received 2026-05-19 00:00:00
Product: Money transfer, virtual currency, or money service — Virtual currency
Issue: Fraud or scam — 
Company: Payward Ventures Inc. dba Kraken
State: CT

Complaint narrative:
My letter to XXXX escalating my XXXX XXXX in the total of {$29000.00} equivalent of XXXX at the time of virtual robbery on XXXX XXXX XXXX. All fraudulent communications were received from XXXX domains and emails that passed all XXXX verification. The following letter to XXXX maps out the sophisticated fraudulent scam in chronological order and includes evidence of direct communication, all sent from the XXXX domain. The evidence and forensic fingerprinting below conclude one of two circumstances, both proving negligence on XXXX 's part : A. Either the phishing emails originated from a compromised Kraken support mailbox/relay ( genuine XXXX signing, but outside the XXXX XXXX XXXX XXXX ; or B. Attackers used insider-leaked PII to craft a credible vishing/phishing sequence from the inside. Kraken has failed to respond adequately. Only receiving boilerplate responses denying any responsibility for the following sequence : To Kraken Legal, Compliance, and Executive Security Leadership, I am writing to formally escalate Ticket # XXXX beyond the tier-one support team that issued your XXXX XXXX XXXX response and to place Kraken on explicit pre-litigation notice. The boilerplate reply I received directing me to file a police report and citing the irreversibility of cryptocurrency transactions reflects a fundamental failure to review the specific facts of this case. Those facts distinguish this incident categorically from a standard third-party phishing scam and implicate Kraken 's own authenticated infrastructure in the loss of {$29000.00} in XXXX. I require a response from Kraken 's Legal, Compliance, or Executive Security leadership within five ( 5 ) business days. Since my initial review of this incident, I have conducted additional forensic examination of the email evidence using XXXXXXXX XXXX native web interface, and I have identified a critical authentication anomaly that I believe Kraken 's own security team will recognize as significant. That finding is detailed in Section IV below and materially strengthens the case that Kraken 's own sending infrastructure or that of an authorized third-party vendor was the instrument of this fraud. I. THE FACTS THAT MAKE THIS CASE UNIQUE On the evening of Sunday, XXXX XXXX XXXX, I received a coordinated series of communications that I will detail below. Every Kraken-branded communication in this sequence originated from XXXX domain, aligning with Kraken 's own official support page ( XXXX, Is this email from Kraken? ) as legitimate, secure senders XXXX, the first on the Secure Email list. I have verified this not merely by visual inspection of display names, but by examining the full email headers of every message received. The XXXX, XXXX, and XXXX authentication records on each email passed verification. These were not display-name spoofs. These were not lookalike domains. These emails were cryptographically authenticated as originating from infrastructure that Kraken 's own DNS records authorize. The sequence of authenticated communications was as follows : At XXXXXXXX XXXX, I received an email XXXX the subject line " Secure Portal, '' containing a professionally designed Kraken-branded template identifying employee XXXX XXXX XXXX Case ID XXXX, and instructing me that I was " on a secure line with a Kraken representative '' and that my assets were " at-risk. '' At XXXXXXXX XXXX and XXXX XXXX additional " Employee Verification '' emails arrived XXXX, identifying employees XXXX XXXX ( Case ID XXXX ) and XXXX XXXX ( Case ID XXXX ), each bearing Kraken 's official logo XXXX the address " XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXXXXXX XXXX '' and links to Kraken 's Legal Disclosures and Privacy Notice. At XXXXXXXX XXXX an email arrived XXXX a domain listed explicitly on Kraken 's official support page as a secure, verified sender with the subject " Action Required : Confirm Your Secret Recovery Phrase. '' This email was formatted in Kraken 's branded template, carried the Kraken Security Team signature, and presented a 12-word Secret Recovery Phrase. I was instructed to use this phrase to set up a Kraken Wallet for account security escalation purposes. Critically, Kraken 's own footer on this email stated : " Kraken will never ask for your password or XXXX codes via email '' language designed to convey authenticity while the email itself was directing me toward a wallet setup that would prove to be the instrument of the theft. At XXXX XXXX I received an automated confirmation XXXX the same authenticated sender with the subject " You added a withdrawal address to Kraken, '' confirming that the " [ Customer ] Kraken Wallet '' had been added as a withdrawal destination from my Kraken Exchange account. The email displayed my Connecticut IP address ( XXXX ) and location, consistent with my own device activity. At XXXX XXXX, a second authenticated email XXXX " XXXX withdrawal initiated, '' again displaying my Connecticut IP address and confirming that funds had been sent to " [ Customer ] Kraken Wallet. '' II. THE TRANSFER OCCURRED BETWEEN TWO LEGITIMATE KRAKEN PRODUCTS This is not a case in which I sent funds to an unknown third-party address or an external wallet of unclear provenance. I transferred XXXX from my Kraken Exchange account to a Kraken Wallet the self-custody wallet application bearing Kraken 's branding, distributed through official app stores, and built and maintained by Kraken. The Kraken Wallet application itself displays a confirmed incoming transaction record showing the receipt of {$29000.00} in XXXX from my Kraken Exchange account. The balance subsequently went to zero, indicating that the funds were swept by whoever held the seed phrase for that wallet a seed phrase that was delivered to me via an XXXX address. The entire fraudulent pathway from the initial contact, to the employee verification, to the recovery phrase delivery, to the withdrawal address addition, to the transfer confirmation ran through Kraken 's own listed authenticated email domains and Kraken 's own wallet product. There is a documented, on-chain transaction record showing XXXX moving from one Kraken product to another. This is not a case where a bad actor impersonated Kraken from the outside. This is a case where Kraken 's own authenticated sending infrastructure was the instrument of fraud. III. THE XXXX INFRASTRUCTURE ATTACK THAT PRECEDED THE KRAKEN CONTACT The attack began with a coordinated compromise of my XXXX account. At XXXX XXXX on XX/XX/XXXX, I received authentic XXXX security alerts XXXX XXXX notifying me that a recovery email had been set up for a linked XXXX account XXXX XXXX ) using my address as the recovery destination. My XXXX Activity logs confirm that two unfamiliar devices accessed my XXXX account on XX/XX/XXXX at XXXX XXXX and XXXX XXXX prior to the Kraken contact sequence. My XXXX was subsequently locked by XXXXXXXX XXXX security systems due to suspicious activity. This XXXX compromise was not incidental. It was the entry point that provided the attackers with the intelligence my Kraken account existence, my email address, my identity necessary to execute the second stage of the attack with the credibility and precision that followed. IV. CRITICAL FORENSIC FINDING : XXXX VERIFICATION FAILURE ON THE FRAUDULENT EMAILS Upon examination of these emails using XXXX 's native web interface the email environment that Kraken 's own support documentation references when instructing customers to verify the legitimacy of Kraken communications I have identified a critical authentication anomaly that materially distinguishes the fraudulent emails from Kraken 's legitimate transactional emails. Kraken 's own published guidance instructs customers to identify legitimate Kraken emails by looking for the XXXXverified blue checkmark beside the sender name in XXXX. XXXX XXXX XXXX XXXX XXXX XXXX XXXX XXXX is the highest tier of email sender verification available, requiring XXXX enforcement at quarantine or reject policy plus a Verified XXXX XXXX that Kraken has registered with email providers including XXXX. XXXX can not be spoofed or replicated by a third-party attacker ; the checkmark only appears when an email is sent through Kraken 's specifically registered, BIMI-authorized sending infrastructure. My examination of the emails received during this incident reveals the following pattern, which I believe Kraken 's security team will recognize as forensically significant : The legitimate transactional emails XXXX specifically the " Withdrawal address added '' notification at XXXX XXXX and the " XXXX withdrawal initiated '' notification at XXXXXXXX XXXX display the XXXXverified Kraken checkmark XXXX XXXX. These emails were generated by my own ( compromised ) Kraken Exchange account taking real actions, and they were sent through Kraken 's XXXXverified sending infrastructure. Their authenticity is consistent with Kraken 's published guidance. The fraudulent emails XXXX including the " Secure Portal '' email at XXXX XXXX and the " Employee Verification '' emails at XXXX XXXX XXXX XXXX and XXXX XXXX do not display the XXXX checkmark in XXXX. They passed XXXX, XXXX, and XXXX authentication, but they did not pass XXXX XXXX. The fraudulent recovery phrase email XXXX XXXX XXXX the email that delivered the 12-word Secret Recovery Phrase used to compromise the destination wallet does not display the BIMI-verified checkmark XXXX despite originating from the exactly same domain as the legitimate transactional emails that do. This discrepancy is not consistent with ordinary external phishing. An external attacker spoofing Kraken 's domain would either fail XXXX outright, or if exceptionally sophisticated pass them all uniformly. They would not produce emails that selectively pass XXXX but fail XXXX within the same domain. That selective failure pattern is consistent with one of two scenarios, both of which implicate Kraken 's own infrastructure or its authorized vendor relationships : First, that the fraudulent emails were sent through a third-party email service provider that Kraken has authorized in its XXXX records for XXXX purposes, but whose sending infrastructure is not covered by Kraken 's XXXX Verified Mark Certificate registration. If that vendor 's systems were compromised, the attacker would be able to send emails passing XXXX under Kraken 's domains but unable to trigger XXXX verification exactly the pattern observed. Second, that the fraudulent emails were sent through Kraken-internal tooling that is authorized to send under Kraken 's domains but is not routed through Kraken 's XXXXcovered production sending infrastructure for example, an internal support tool, a helpdesk integration, or an administrative sending channel accessible to insider personnel. I note for the record that Kraken publicly disclosed in XXXX XXXX two separate insider incidents in which support employees were recruited by criminal networks to access customer data. The timing and methodology of those disclosures are directly relevant and to the second scenario described above. I am not, at this time, asserting which of these two scenarios produced the fraudulent emails. I am asserting that the XXXX verification failure conclusively rules out the explanation of " ordinary third-party phishing '' and forensically narrows the source of these emails to infrastructure that Kraken either controls or has authorized. Kraken is the only party in possession of the records necessary to determine which. V. THE MATERIAL IMPLICATIONS OF KRAKEN 'S OWN PUBLISHED GUIDANCE Kraken 's support documentation specifically directs customers to use the XXXX checkmark as the verification standard for legitimate Kraken emails. I followed this guidance only after the loss occurred, and the XXXX failure pattern was decisive in confirming that I had been defrauded through compromised authorized infrastructure rather than ordinary phishing. However, Kraken 's published guidance does not adequately disclose to customers that emails can pass XXXX, XXXX, and XXXX and therefore appear authenticated in most email clients including the Spark client I was using at the time of the incident while still failing XXXX XXXX. The fraudulent emails I received were rendered as authenticated and trustworthy in my email client. The XXXX checkmark is only visible in specific email environments, and its absence is not flagged as a warning to the user. This legal implication is significant. Kraken instructed customers to rely on a verification standard ( BIMI ) without adequately warning that emails sent from Kraken 's own listed sender domains could appear fully authenticated to users while still failing that standard. That gap in disclosure, combined with the fact that the fraudulent emails originated from infrastructure Kraken authorized, is the foundation of a material consumer-protection claim under the Connecticut Unfair Trade Practices Act. VI. LEGAL NOTICE I have filed a complaint with the FBI Internet Crime Complaint Center ( IC3 Submission ID : XXXX, filed XXXX XXXX XXXX ). I have reported this incident to local Connecticut law enforcement. I am actively seeking legal counsel and am evaluating claims under the Connecticut Unfair Trade Practices Act ( CUTPA ), Conn. Gen. Stat . 42-110a et seq., including potential per se violations tied to Connecticut 's data breach statute, 36a-701b ( j ). I am also evaluating claims for negligence, breach of contract, negligence per se based on Kraken 's obligations under its money transmitter license obligations and applicable cybersecurity standards, and breach of express and implied warranties of security tied to Kraken 's published guidance regarding email authentication. I will be filing complaints with the Connecticut Department of Banking, the Connecticut Attorney General 's Consumer Protection Unit, and FinCEN. I am not prepared to accept Kraken 's characterization of this incident as a standard third-party phishing loss. The authenticated email trail, the on-chain transaction record between two Kraken products XXXX the XXXX verification failure isolating the fraudulent emails to Kraken-authorized but XXXX-unverified infrastructure, and the circumstances of Kraken 's own recent insider security disclosures collectively raise serious questions about the integrity of Kraken 's sending infrastructure that deserve a thorough, good-faith internal investigation not a boilerplate response. I am requesting the following from Kraken within five ( 5 ) business days : First, written acknowledgment that this escalation has been received by Krakens Legal, Compliance, and/or Executive Security team not tier-one support. Second, identification of the specific sending infrastructure, including any third-party email service provider, used to transmit XXXX I received on XXXX XXXX XXXX If those emails were transmitted through Kraken 's own production mail servers, please confirm. If they were transmitted through a third-party vendor, please identify the vendor and confirm whether that vendor 's XXXX Verified Mark Certificate registration is current. Third, identification of the specific sending infrastructure used to transmit XXXX '' Confirm Your Secret Recovery Phrase '' email I received at XXXX XXXX on XXXX XXXX XXXX, and an explanation of why this email failed XXXX XXXX while the legitimate XXXX received later that evening passed XXXX XXXX. Fourth, confirmation of whether any anomalous activity, unauthorized access, or vendor compromise was detected in any of Kraken 's authorized sending infrastructure internal or third-party on or around XXXX XXXX XXXX Fifth, confirmation of whether any internal investigation has been opened in connection with this ticket, and whether the facts described in this letter have been escalated to Kraken 's security incident response team. Sixth, Kraken 's position on remediation or restitution, given the totality of the facts described above. I wish to resolve this matter directly with Kraken before further legal proceedings are initiated. I am not approaching this with hostility I am approaching this as a customer who intentionally selected Kraken as my XXXX XXXX of choice due to its reputation as the most secure US-Based Exchange, yet find myself defrauded through what the forensic evidence indicates was a failure of Krakens own authenticated sending infrastructure or its authorized vendor relationships. I have preserved all relevant evidence, including full email headers, screenshots from XXXX 's native interface, the IC3 complaint confirmation, Kraken Wallet transaction records, and XXXX account activity logs documenting the unauthorized device access that preceded the Kraken contact sequence. I am prepared to share this evidence with Kraken 's Legal, Compliance, or Executive Security team upon receipt of confirmation that this matter has been appropriately escalated. - Sincerely, [ Customer Name and Address Removed as per the CFBP submission guidelines ]

Company public response: Company has responded to the consumer and the CFPB and chooses not to provide a public response
Company response to consumer: Closed with explanation