new developments Mica And nacha provide us with an acronym-heavy bonus digital assets Thoughts of the Week.
Mica
growing pains
“The regulations are quite new for both the regulators and the entities in the market. We are learning how to be fully compliant, and the regulators are learning how to work with crypto assets.”
“Most of the regulators we’ve had the chance to talk to already understand the market, but it’s not the standard; not all of them do.”
MiCA deadline and Polish cryptocurrency
“Very few licenses are issued in Europe. In some countries, the historical allocation period that allows businesses to operate without a license has already been completed.
“For some jurisdictions, the deadline is still at the end of June. From what we see from the market, not all organizations will manage to obtain a license before that date.
“This will greatly change the business landscape of crypto assets. For example, we have about 2,000 VASP organizations in Poland. As far as I know, we are the only organization that has a MiCA license. So I think you can imagine how many organizations will have to close down business from the second half of this year.”
Cost of MiCA
“This is a pretty big shift in thinking about how you run a business. And it’s definitely a costly process. So not all assets will be able to meet all the requirements. That’s the most important part; there’s no room for small players and it’s going to be really hard for new crypto businesses to get started.”
“In years past, if you had an idea and the money to develop a product, you could start and see how the market would react to your offering. Now even thinking about starting is very costly, you have to get a license and you really have to be prepared.”
“This makes it difficult to get started for organizations considering joining the crypto market. In Europe, in my opinion, the market will be consolidated by larger players and we are already seeing this happening.”
MiCA and FCA crypto roadmap
“In the past, our target market was not the UK, but I think it will be in the future. First of all, we need to get a license from there because MiCA does not allow you to operate in the UK.”
“As far as I know, there is currently a big project within the FCA to create a regulation similar to MiCA. So from our perspective, we will wait until this is finished.
“We have decided to apply for a license there, but this is still a plan for the future. I don’t know how long it will take for the FCA to fully prepare this. From what I know, they want to build something quite similar to what we have in the European Union.
“I don’t know if it will be at the same level of difficulty as MiCA, because what has to be said is that MiCA is a pretty heavy regulation.”
– Mateusz KaraFounder and CEO of Ari10 Morfik Finance Group
nacha
“Deadline is June 20, 2026 nacha‘s updated ACH fraud rules are here and apply to any organization sending an ACH payment, regardless of volume. For many businesses, the compliance conversation has focused on documenting the fraud response plan, but the more important question is whether organizations have the visibility to detect fraud before any payments are completed.
“This distinction is important. The most damaging fraud schemes rarely originate in the payment file itself. They start upstream: a vendor bank record silently updated in an ERP system, a payroll direct deposit routed 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 appears completely legitimate.”
Business email compromise and vendor master manipulation
“Consider one of the most common attack vectors in enterprise payments today: primary merchant fraud. A fraudster gains access to a vendor portal or directly contacts accounts payable by impersonating a legitimate merchant and requesting a bank account change. If the organization does not have controls in place to flag unauthorized changes to merchant payment records, the updated account number is rolled over to the next payment transaction through the purchase and without review. The ACH transaction is cleared. The loss is discovered weeks later when the actual merchant reports non-payment.”
“Nacha’s new rules require risk-based processes and procedures to detect potential fraudulent transactions. However, a process that only examined the outgoing payment file would completely miss this scheme. The fraud signal was present within the business application, not in the bank file.”
Payroll routing
“A similar dynamic is playing out with payroll fraud. Employees or malicious actors using compromised credentials change direct deposit details on HR and payroll platforms. In organizations where payroll changes do not trigger independent review or audit alerts, these changes can persist for multiple pay cycles before being detected.”
“ACH entries are authorized by the payroll system. They match employee records. There is nothing in the payment order that indicates anything is wrong.
“Effective fraud prevention here requires not only reviewing the payroll record before it is submitted, but monitoring changes to pay-related data fields in HR systems.”
Separation of duties and abuse of access
“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 opportunity to commit fraud without outside help. Similarly, a user who can change payroll bank details and approve the next payment run represents an uncontrolled risk that no payment file review will capture. Consistently applied segregation of duties controls across ERP, purchasing and HR systems are a key element of any reliable fraud prevention posture under the new rules.”
Transaction lifecycle visibility status
“These scenarios point to a broader principle that Nacha’s new framework implicitly supports: Understanding how a transaction was created, modified, approved, and released becomes as important as reviewing the final payment order itself. Organizations need to ask whether they have visibility across the entire chain of custody—ERP, purchasing, HR, payroll, and the financial systems from which payment decisions originate.”
“This is not a new idea in theory, but in practice it has been underinvested in. Many organizations have strong controls at bank borders and weak controls on the business practices that feed it. Nacha’s updated rules provide an opportunity and an imperative to close this gap.”
What does compliance actually require?
“The flexibility of the rule is intentional. Nacha has not recommended a specific technology or methodology, recognizing that organizations vary significantly in size, complexity and system structure. However, this flexibility should not be read as a license 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-related data before a transaction reaches their financial institution. They should map the systems involved in the creation of ACH payments and evaluate where controls are in place and where they are not. They should engage early with financial institutions and, where appropriate, third-party processors to both understand existing monitoring tools and establish clear escalation paths.”
For organizations running SAP, Oracle or similar ERP environments, two specific talent gaps should be immediately taken into consideration
Ensure continuous monitoring of payment-related master data and access rights across ERP and financial systems
“Nacha’s rules require risk-based procedures that can detect fraudulent transactions before they are sent. For most organizations, this means having automated controls that detect unauthorized or abnormal changes to merchant bank 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 as they occur, before those changes are used in an outbound ACH transaction.”
Implement and enforce segregation of duties controls in systems where ACH payments are processed
“A user who can create or modify a merchant record and at the same time approve or release a payment represents a serious fraud risk that no amount of bank-side controls can prevent. Meeting the spirit of Nacha’s new rules requires organizations to identify and remediate conflicting access not just in the treasury or banking system, but in every application involved in the payment lifecycle.”
“Pathlock’s SoD analysis and access governance capabilities extend across the entire application landscape, including ERP, HR, purchasing and financial planning systems, providing organizations with a defensible, auditable record of who has access to payment-related functions and whether those rights are appropriately restricted.”
– Chris RadkowskiSAP GRC expert road lock
