The Block Inc. $40M AML Settlement: What Every FinTech Compliance Team Must Learn

When a company grows faster than its compliance function, the gap between the two does not stay theoretical for long. The enforcement actions against Block Inc. in 2025 demonstrate exactly what that gap looks like when regulators eventually examine it: a SAR backlog of nearly 170,000 unprocessed alerts, Bitcoin transactions routed to terrorism-connected wallets without interdiction, anonymous accounts exploited by bad actors, and mixing service transactions rated at the wrong risk level for years. 

On April 10, 2025, NYDFS Superintendent Adrienne A. Harris announced that Block Inc. would pay a $40 million penalty for significant failures in its Bank Secrecy Act and AML compliance program, which violated the Department's money transmitter and virtual currency regulations. That settlement followed a separate action three months earlier. In January 2025, in a coordinated enforcement action by 48 state financial regulators, Block agreed to pay an $80 million fine and undertake corrective action for violations of the Bank Secrecy Act and AML laws. 

By the time the final settlement landed, Block had agreed to pay a combined total of over $175 million to regulators across the United States, alongside commitments to independent monitors and programme overhauls that carry their own significant cost and operational disruption.

{{snippets-guide}}

Background: What Block Is and Why It Was In Scope

Block Inc., the company behind Cash App, Square, and other financial products, is not a bank. It operates as a licensed money transmitter and, from 2018 onwards, as a licensed virtual currency business in New York. Block has been licensed in the State of New York to operate as a money transmission business since 2013 and as a virtual currency business through Cash App since 2018. 

That dual-licence status is significant. It means Block was subject to both standard BSA/AML obligations applicable to money transmitters and the additional virtual currency compliance requirements under NYDFS's BitLicense framework. Failures in either area, or in the interaction between the two, fell within NYDFS's jurisdiction. The investigation that produced the April 2025 consent order covered examinations conducted between spring 2021 and autumn 2022, meaning the failures that generated the penalty date largely to the period of Cash App's most rapid growth.

What the NYDFS Found: The Six Core Failures

‍

1. The SAR Backlog

The most operationally striking finding in the consent order is the scale of the transaction monitoring backlog. Between 2018 and 2021, Block let a backlog of SAR alerts grow from 18,000 to over 169,000, delaying critical reports of potentially illicit activity. 

This backlog was caused in part by Block's inability to predict the impact of Cash App's growing customer base on alert volumes and staffing needs, as well as the increase in alerts generated by the implementation of new transaction monitoring tools. The consequence was that SARs were being filed not within the required timeframe but sometimes over a year after the underlying alert was first generated. 

Between 2018 and 2021, Block experienced a significant backlog in transaction monitoring alerts that caused Block to file some SARs over a year after the alert was first generated. 

2. Bitcoin Screening Thresholds Set Above Zero

Block used two blockchain analytics vendors. Concerning one vendor, Block's settings did not generate alerts on Bitcoin transactions until the recipient's wallet had more than 1% exposure to terrorism-connected wallets, and Block did not blacklist terrorism-connected wallets until exposure exceeded 10%. 

The NYDFS was explicit about why this is not acceptable. The regulator stated: "Any amount of funds transferred to terrorism-connected wallets is illegal, and setting threshold alerts above 0% without a risk-based analysis supporting that decision falls short of the regulatory requirement that licensees implement risk-based policies, procedures, and practices to ensure compliance with BSA and OFAC regulations." 

OFAC's strict liability standard means that transferring any value to a terrorism-connected wallet is a potential sanctions violation, and configuring a screening system to allow transactions until a 10% exposure threshold is reached is not a risk-based decision. It is an operational misconfiguration that created a direct compliance gap.

3. Mixing Service Transactions Rated as Medium Risk

The consent order also found that Block rated transactions involving anonymising services (mixers) at the wrong risk level. Block rated transactions with exposure to anonymity-enabling mixing services as "medium" risk, when the department said it should have been rated as "high," based on its guidance. 

Mixing services exist specifically to obscure the origin and destination of cryptocurrency transactions. They are a well-documented money laundering typology, flagged in FinCEN guidance, FATF reports, and multiple NYDFS advisories. Treating exposure to mixing services as a medium-risk indicator rather than a high-risk indicator reflects either a failure to calibrate the monitoring system against current regulatory guidance or an operational decision that was not revisited as guidance evolved.

4. Inadequate Customer Due Diligence and Restricted Accounts

Cash App's onboarding model included a category of "restricted" accounts that permitted fiat transactions up to a defined limit without requiring full identity verification. The compliance logic was that the transaction limit would constrain risk. The problem was the absence of a corresponding limit on the number of accounts a single individual could open.

NYDFS was concerned with Block's oversight of restricted accounts on Cash App that permitted fiat transactions under a certain limit without requiring full identity verification. This allowed bad actors to complete transactions on the platform by opening multiple restricted accounts. Block imposed a transaction limit of $1,000 in a rolling 30-day period for restricted accounts using the same linked financial instrument. However, the monetary limit, without a limit on the number of accounts that could be opened, did not constitute an effective control, as individuals could create multiple restricted accounts using multiple financial instruments, thereby circumventing the transaction limits. 

5. Insufficient Sanctions Screening

The AML failures were compounded by deficiencies in sanctions screening. The NYDFS investigation revealed deficiencies including insufficient sanctions screenings alongside inadequacies in customer due diligence and delayed SAR filings. 

The Bitcoin threshold configuration described above represents one dimension of the sanctions gap. More broadly, the combination of anonymous transaction processing, restricted account workarounds, and backlogged alert review created a system in which sanctioned counterparties had multiple pathways to conduct transactions that would not be interdicted in real time. 

6. Compliance Infrastructure That Did Not Scale With the Business

All of the above failures share a common root cause that the NYDFS consent order and the company's own public statement both acknowledge. Block's AML program "failed to adequately consider the substantial risks posed to an entity of its new size and complexity," according to NYDFS. Superintendent Harris stated: "The rapid growth of Block's Cash App absent a robust compliance function created risk and vulnerabilities that violated the rules financial services companies operating in New York must adhere to." 

This is the structural failure. Cash App grew very fast between 2019 and 2020, adding millions of users and expanding its product offering to include Bitcoin transactions, at a pace that its compliance infrastructure was not resourced or designed to match. Alert volumes increased faster than review capacity. Risk frameworks calibrated for a smaller customer base were not updated for a larger one. The gap between the size of the business and the size of the compliance function widened until it became visible to regulators.

The Regulatory Consequences

The penalties were significant, but the non-monetary consequences carry equal weight for how Block operates going forward.

Financial penalties:

• $40 million to NYDFS (April 2025)
• $80 million to 48 state regulators via CSBS (January 2025)
• $55 million in civil penalties to the CFPB, plus up to $120 million in consumer redress (separate action)

Operational remediation:

• Block must retain an Independent Monitor to oversee the company's compliance improvements and evaluate its corrective actions going forward. 
• Block committed to resolving alert backlogs, increasing compliance staffing, limiting account creation, implementing additional controls to prevent bad actors from re-entering the platform, and updating its BSA/AML and OFAC compliance practices.
• Block CEO Jack Dorsey signed the consent order, which also prevents the company from writing off the penalty as a tax deduction. 

The independent monitor requirement is not a formality. It means a third party with regulatory standing will assess Block's compliance programme, report findings to NYDFS, and track whether remediation commitments are met. It is the regulatory equivalent of placing a business under active supervision, and it creates ongoing reputational and operational constraints on how the compliance function is managed.

What FinTech Compliance Teams Must Take From This

The Block case is not an outlier. It is a high-profile instance of a pattern that regulators in the US and elsewhere have identified repeatedly: FinTechs that grow product and customer volumes without proportionally building compliance infrastructure, and that discover the gap only when a regulatory examination makes it visible. The lessons are direct.

Compliance Staffing Must Scale With Customer Volume

The SAR backlog at Cash App did not appear overnight. It grew from 18,000 to 169,000 alerts over three years, which means it was visible as a trend long before it became an enforcement issue. The backlog was caused in part by Block's inability to predict the impact of Cash App's growing customer base on alert volumes and staffing needs. A compliance team that cannot forecast how alert volume will change as the customer base grows is not resourced for the business it is operating. 

Compliance leaders should model alert volume projections as a function of customer acquisition plans. When onboarding targets increase by 50%, the question of how many additional alerts that will generate, and whether current staffing can process them within required timeframes, must be answered before the growth happens, not after the backlog accumulates.

Blockchain Analytics Configuration Requires Active Governance

The Bitcoin screening threshold failure is a governance problem, not a technology problem. Block had blockchain analytics vendors in place. The issue was that the configuration of those tools set thresholds that did not satisfy regulatory requirements, and that configuration was not reviewed against OFAC standards and NYDFS guidance before being deployed.

FinTechs operating virtual currency products should:

• Document the configuration of every blockchain analytics tool, including alert thresholds for exposure to high-risk wallet categories.
• Review that configuration against current OFAC guidance and supervisory expectations at least annually, and whenever OFAC or the relevant regulator issues updated typology guidance.
• Treat any non-zero threshold for terrorism-connected wallet exposure as a configuration requiring specific documented justification, since the NYDFS consent order makes clear that the default expectation is a zero threshold.

Transaction Monitoring Rules Must Reflect Current Typology Guidance

The mixing service risk rating failure reflects a monitoring calibration that was not updated as regulatory guidance on mixing services hardened. FinCEN issued guidance on mixing services as a high-risk money laundering typology, and NYDFS guidance on virtual currency compliance is explicit about the elevated risk they represent. A monitoring system that rates them as medium risk is not aligned with the regulatory standard.

Monitoring rule calibration should be a documented, periodic process. When a regulator issues new typology guidance or a supervisory advisory, compliance teams should assess whether existing monitoring rules reflect the updated risk assessment and update them where they do not. That review should be logged, because it forms part of the evidence that the compliance programme is responsive to current standards.

Control Design Must Account for Circumvention

The restricted account gap illustrates a principle that applies to all compliance controls: a control designed without considering how it can be circumvented is not a complete control. The transaction limit on restricted accounts was a reasonable starting point, but without a corresponding limit on account creation it was not an effective barrier.

Before deploying any compliance control, compliance teams should test it against the most obvious circumvention scenarios. For consumer-facing products, those scenarios often involve:

• Opening multiple accounts to aggregate transaction capacity.
• Using multiple payment instruments to stay below monitoring thresholds.
• Using third parties to complete transactions on behalf of a restricted individual.

Controls that fail straightforward circumvention testing should be redesigned before deployment, not after regulators find the gap.

{{snippets-case}}

Rapid Growth Requires a Compliance Readiness Assessment

The most broadly applicable lesson from the Block case is that rapid business growth requires a formal compliance readiness assessment before it happens. This is not a one-time exercise. Every time a FinTech launches a new product, enters a new market, onboards a materially different customer segment, or adds a new payment channel, the compliance implications of that change must be assessed and resourced.

The assessment should cover:

• How will alert volumes change, and does current staffing capacity support them?
• Does the risk framework reflect the risk profile of the new product or customer segment?
• Are the monitoring rules calibrated for the new activity?
• Does the KYC model address the specific risks of the new channel?
• Are there any new regulatory obligations, for example virtual currency regulations, that apply to the new product?

None of these questions are difficult to ask. The Block case demonstrates what happens when they are not asked systematically before growth outpaces compliance capacity.

Conclusion

The Block Inc. settlement is a detailed public record of what BSA/AML programme failure looks like at scale, how it develops over time, and what regulators will do when they find it. The failures identified in the consent order, an overwhelming SAR backlog, misconfigured blockchain analytics, inadequate KYC controls, and monitoring rules out of step with regulatory guidance, are not exotic or technically complex. They are the result of a compliance function that did not grow with the business it was supposed to govern.

FinTech compliance teams that review this case as an abstract enforcement story rather than a practical operational reference are missing its value. The consent order is, in effect, a checklist of the control failures that NYDFS will look for in its next examination of a virtual currency and money transmission licensee. The question for every compliance team operating in that space is whether their programme would produce a different result.

sanctions.io is a highly reliable and cost-effective solution for real-time screening. AI-powered and with an enterprise-grade API with 99.99% uptime are reasons why customers globally trust us with their compliance efforts and sanctions screening needs.

‍

To learn more about how our sanctions, PEP, and criminal watchlist screening service can support your organisation's compliance program: Book a free Discovery Call.

‍

We also encourage you to take advantage of our free 7-day trial to get started with your sanctions and AML screening (no credit card is required).

‍