FinCEN has withdrawn a six-year-old proposal that would have significantly lowered the threshold for collecting and transmitting identifying information on cross-border financial transactions, extending those requirements to cryptocurrency. For many compliance teams, this news brings a mix of relief and confusion.
The Question at Hand
If your team handles cross-border payments or digital assets, you've probably spent years wondering if this rule would take effect. Maybe you scoped system changes, drafted procedures, or decided to wait. Now that the proposal is gone, a practical question arises: Do you keep the controls you built in anticipation, slow down, or unwind them? The answer depends on how you view the relationship between a proposed rule and your program's design. Practitioners are divided on this, and both sides have valid points.
The Case for Pulling Back
One argument is about operational honesty. A control exists to manage a risk or meet a requirement. If the requirement no longer exists, maintaining the control costs time, money, and attention without a purpose. Compliance teams are often understaffed, and every manual step competes with other priorities.
Another argument concerns data. Collecting more identifying information means more data to secure, retain, and eventually dispose of. Your Record Retention Policy and security posture must account for it. Holding data with no regulatory purpose is a liability.
Credibility is also at stake. Employees and business partners tolerate friction when they understand the reason. Asking a team to keep a burdensome step "just in case" erodes trust. If your explanation is that the rule was withdrawn but you're keeping the step anyway, expect fair questions.
The Case for Staying the Course
The counterargument starts with a simple observation: a withdrawn proposal is not a settled question. The concerns that motivated the proposal, like tracking value across borders and treating cryptocurrency, haven't disappeared. Withdrawal means this specific rule isn't proceeding, not that the issue is closed.
Another argument is about risk, independent of regulation. Many institutions collect and verify identifying information on cross-border and digital asset activity based on their own risk assessments. A control justified by your risk assessment doesn't depend on a rule. Scrapping a proposal puts more weight on your judgment since you can't point to a regulator's directive.
Rebuilding costs are also a consideration. Programs that dismantle capabilities with each regulatory change pay twice: once to dismantle and again to rebuild. If the infrastructure is already built and tested, maintaining it in a lighter form may be cheaper than starting over later.
Where Practitioners Actually Land
Most experienced teams don't pick a side cleanly. They sort their controls into three groups.
Controls tied to existing obligations. These stay. A withdrawn proposal doesn't change existing requirements, so don't let the news affect areas it doesn't touch.
Controls justified by your own risk assessment. These stay, but document the reasoning. If you collect information because your institution's risk profile calls for it, say so in writing. This keeps the control defensible on its own merits.
Controls built only for the anticipated rule. These need a hard look. Assess what risk each one addresses, what it costs, and whether a smaller version would suffice. Some teams pause these rather than remove them, keeping the design documents on hand.
The common thread is documentation. Whatever you decide, record the decision, the date, and the reasoning. A program that can explain its changes is easier to defend than one that drifts.
Cryptocurrency deserves its own note. Digital assets frequently appear in regulatory discussions, and a withdrawn proposal is just one part of a longer story. Teams that treat crypto exposure as a standing item in their risk assessment, rather than reacting to each proposed rule, tend to be less affected by such announcements.
Our Take
The strongest position is neither to dismantle nor to hold everything in place. Build your program around your risk assessment, not around the rulemaking calendar.
A rule proposal is a signal, not an instruction. When one arrives, assess whether your current controls match your actual exposure. When one is withdrawn, ask the same question. The answer may change your actions, but the process remains consistent, protecting you from both over-building and under-building.
There's a tradeoff here. Keeping controls beyond what's required costs money and adds friction, and some of that cost may be wasted. Cutting them loose risks a scramble if expectations shift again. We'd accept the first cost over the second for controls that address risks identified by your own assessment, and we'd drop controls that only existed to satisfy a rule that's no longer coming.
This week's work is straightforward. Inventory the controls you built or planned for this proposal. Sort them into the three groups above. Document your decisions. Then inform the teams who live with those controls about what changed and why. People can accept a program that adjusts when the facts change, as long as it's explained plainly.
