New developments with MiCA and Nacha provide us with an acronym-heavy bonus digital assets Thoughts of the Week.
MiCA
Growing pains
“Regulations are quite new, both for regulators and for the entities that are in the market. We are learning how to be fully compliant, and regulators are learning how to work with crypto entities.
“Most of the regulators we have had a chance to speak with already understand the market, but it’s not the standard; not all of them do.”
MiCA deadline and Polish crypto
“There are very few licenses granted in Europe. In some of the countries, the grandfathering period that allows entities to operate without a license is already complete.
“For some of the jurisdictions, the deadline is still at the end of June. And what we see from the market is that not all of the entities will succeed in getting the license before then.
“It will change the business landscape of crypto entities a lot. For example, in Poland, we have around 2,000 VASP entities. As far as I know, we are the only ones that have a MiCA license. So, I think you can imagine how many entities will need to shut down the business starting from the second half of this year.”
MiCA’s cost
“It’s quite a big change of thinking in how you run a business. And it’s definitely a costly process. Not all of the entities will be able to meet all the requirements because of that. It’s the most crucial part; there is no room for small players, and it will be really hard for new crypto businesses to start.
“In the previous years, if you had an idea and the money to build a product, you could start and see how the market responds to your offer. Right now, to even think about starting, you need to obtain a license that costs a lot, and you need to be really prepared.
“It’s making it hard to start for the entities that are thinking about joining the crypto market. In my opinion, in Europe, the market will be consolidated by the bigger players, and we already see that happening.”
MiCA vs. FCA crypto roadmap
“The UK was not our target market in the past, but I think that it will be in the future. First, we need to obtain the license there because MiCA doesn’t allow you to operate within the UK.
“As far as I know, right now, there is a big project within the FCA to build a regulation similar to MiCA. So, from our perspective, we will wait till it’s done.
“We already made a decision that we will apply for a license there, but it’s still a plan for the future. I don’t know how long it will take for the FCA to fully prepare it. From what I know, they want to build something that is quite similar to what we have in the European Union.
“I don’t know if it will be the same hard level as MiCA is, because what needs to be said is that MiCA is quite a heavy regulation.”
– Mateusz Kara, founder of Ari10 and CEO of Morphic Financial Group
Nacha
“The June 20, 2026, deadline for Nacha‘s updated ACH fraud rules has arrived, and it applies to every organization that sends ACH payments, regardless of volume. For many businesses, the compliance conversation has focused on documenting a fraud response plan, but the more important question is whether organizations have the visibility to detect fraud before any payments are completed.
“That distinction matters. The most damaging fraud schemes rarely originate in the payment file itself. They begin upstream: a vendor banking record quietly updated in an ERP system, a payroll direct deposit redirected through a compromised HR portal, an approval workflow bypassed by a user with excessive access. By the time the ACH instruction reaches the bank, the fraud has already succeeded. The payment looks entirely legitimate.”
Business email compromise and vendor master manipulation
“Consider one of the most common attack vectors in corporate payments today: vendor master fraud. A fraudster gains access to a supplier portal or contacts accounts payable directly, impersonating a legitimate vendor and requesting a bank account change. If the organization lacks controls to flag unauthorized modifications to vendor payment records, the updated account number flows through procurement and into the next payment run without scrutiny. The ACH transaction clears. The loss is discovered weeks later, when the real vendor reports non-payment.
“Nacha’s new rules require risk-based processes and procedures to identify potentially fraudulent transactions. But a process that only reviews the outbound payment file will miss this scheme entirely. The fraud signal existed inside the business application, not in the bank file.”
Payroll diversion
“A similar dynamic plays out in payroll fraud. Employees, or bad actors using compromised credentials, modify direct deposit details inside HR and payroll platforms. In organizations where payroll changes do not trigger independent review or audit alerts, those modifications can persist for multiple pay cycles before detection.
“The ACH entries are authorized by the payroll system. They match employee records. Nothing in the payment instruction indicates a problem.
“Effective fraud prevention here requires monitoring changes to payment-relevant data fields in HR systems, not just reviewing the payroll register before it is submitted.”
Segregation of duties and access abuse
“This risk vector is often overlooked entirely: internal users with excessive or conflicting access rights. An employee who can both create a vendor record and approve a payment has the means to execute fraud without external assistance. Similarly, a user who can modify payroll bank details and approve the subsequent pay run represents an uncontrolled risk that no payment-file review will catch. Separation of duties controls, applied consistently across ERP, procurement, and HR systems, are a foundational element of any credible fraud prevention posture under the new rules.”
The case for transaction lifecycle visibility
“These scenarios point to a broader principle that Nacha’s new framework implicitly supports: understanding how a transaction was created, modified, approved, and released is becoming as important as reviewing the final payment instruction itself. Organizations need to ask whether they have visibility across the full chain of custody: ERP, procurement, HR, payroll, and financial systems where payment decisions originate.
“This is not a new idea in theory, but it has been underinvested in practice. Many organizations have strong controls at the bank boundary and weak controls in the business applications that feed it. Nacha’s updated rules provide an opportunity, and an obligation, to close that gap.”
What compliance actually requires
“The rule’s flexibility is deliberate. Nacha has not prescribed a specific technology or methodology, recognizing that organizations vary significantly in size, complexity, and system landscape. But that flexibility should not be read as permission for superficial compliance. A documented fraud response plan is a starting point, not a finish line.
“Organizations should evaluate whether their current capabilities allow them to detect unauthorized changes to payment-relevant data before a transaction reaches their financial institution. They should map the systems involved in originating ACH payments and assess where controls exist and where they do not. They should engage their financial institution and, where applicable, third-party processors early, both to understand available monitoring tools and to establish clear escalation paths.”
For organizations running SAP, Oracle, or similar ERP environments, two specific capability gaps deserve immediate attention
Establish continuous monitoring of payment-relevant master data and access rights across ERP and financial systems
“Nacha’s rules require risk-based procedures capable of identifying fraudulent transactions before they are submitted. For most organizations, that means having automated controls that detect unauthorized or anomalous changes to vendor banking records, payroll direct deposit details, and user access privileges in real time.
“Pathlock provides continuous control monitoring across SAP, Oracle, and connected financial systems, alerting compliance and finance teams to changes in payment-sensitive data fields the moment they occur, before those changes can be exploited in an outbound ACH transaction.”
Implement and enforce segregation of duties controls across the systems that originate ACH payments
“A user who can create or modify a vendor record and also approve or release a payment represents an unmitigated fraud risk that no bank-side control will prevent. Meeting the spirit of Nacha’s new rules requires organizations to identify and remediate conflicting access across every application involved in the payment lifecycle, not just the treasury or banking system.
Pathlock’s SoD analysis and access governance capabilities extend across the full application landscape, including ERP, HR, procurement, and financial planning systems, giving organizations a defensible, auditable record of who has access to payment-relevant functions and whether those rights have been appropriately constrained.”
– Chris Radkowski, SAP GRC expert at Pathlock