What the BCRA changed in February forces fintechs to decide where each workload runs

On February 5, 2026, Argentina's Central Bank (BCRA) issued Comunicación "A" 8398. Eight days later, the "A" 8401 incorporated the new pages into the consolidated text. Between the two, they did something most fintech engineering teams still haven't fully sized up: they placed Payment Service Providers under the same technology risk management regime that governs banks, and gave them 180 days to comply.

If you operate a wallet, a payments system, or any product registered as a PSP with the BCRA, that clock is already ticking. And compliance is not a paperwork exercise you settle with a document. It is a series of architecture decisions that, if they weren't factored in from the design stage, force you to redo things that are already in production.

What changed, specifically

‍

The regime of Minimum Requirements for the Management and Control of Technology and Information Security Risks existed before. What changed in February has three edges that matter for how your infrastructure is built.
First: PSPs are now covered entities. Until February, the full regime applied to financial institutions and systemically important payment infrastructures. It now also reaches the PSPs on the BCRA registry, with a 180-day window to implement the required adjustments. A payments fintech that had been operating under its own security criteria now has to demonstrate compliance with a formal framework.
Second: the rules for outsourcing critical services got stricter. Before outsourcing a technology or cybersecurity service deemed critical, you now have to notify the BCRA at least 60 calendar days in advance, reporting the service, the locations, the provider, and any subcontractors. And the third party must formally commit to allowing BCRA audits. That includes your cloud provider, your integrator, whoever runs your migration.
Third — and the one that most constrains architecture: for outsourcing abroad, providers must sit in jurisdictions aligned with FATF standards, and key documentation — books, files, relevant records — must be kept in Argentina. This has direct consequences for which region of your cloud provider you can use and how you structure data safeguarding.

The point worth keeping in sight: the regime is explicit that outsourcing does not release the entity from its responsibilities. You can delegate execution, not regulatory responsibility. If your cloud provider falls short, the problem is yours before the BCRA.

Why this is an architecture problem, not paperwork

The easy reading of a rule like this is to treat it as a compliance checklist: a list of requirements the legal team ticks off and files away. That reading is the one that later produces the incident.
What the 8398 raises, at bottom, is a question that is purely architectural: where each workload has to run. The transactional core is not the same as a development environment. A database holding sensitive customer data in production is not the same as an analytics model trained on anonymized data. An anti-fraud engine is not the same as a corporate website. Each one carries a different level of criticality, and the regime forces you to demonstrate that you understand that difference and that your infrastructure reflects it.
That is not solved with a written policy. It is solved with concrete decisions: what goes in which region, how access is segmented, how traceability is structured so that an event is auditable, where backups reside, what can be outsourced and under what conditions. Decisions that live in the Terraform, not in the compliance document.
The practical consequence is that the moment to bring in whoever designs the infrastructure is not after legal has interpreted the rule. It is before. An architecture designed without the rule in mind and “adjusted” afterwards almost always costs more than one designed with the rule as a parameter from the start.

The deadline is the real parameter

One hundred and eighty days is not much when what's at stake is reorganizing where the workloads of an operation that cannot stop actually run. And here comes the tension we know well from any production infrastructure project: you can't halt the operation to comply, but you can't ignore the deadline either.
The way to resolve that tension is not technical; it is a matter of sequence. The first step is not migrating anything: it is mapping. Which workloads you have, how critical each one is under the rule's criteria, what is outsourced and under what conditions, which providers need to take on the audit commitment. Only with that map can you define what has to move, what has to be reconfigured, and what already complies. Most compliance efforts that stall do so because they started executing before that map was complete.
There is a second order of magnitude worth anticipating: the rule is not static. The BCRA has been updating this framework at a pace with no parallel in other markets — the 8398 and the 8401 are just the latest in a sequence. An architecture that complies today but lacks the flexibility to adapt to the next communication is a solution that will generate rework within a year. The design question is not just “does it comply with the 8398”; it is “can it adapt to the 8410 without being rebuilt”.

What I would do if I ran a PSP with the clock ticking

I would start with the map of workloads and their criticality, before touching any infrastructure. Without that diagnosis, every move is a blind one.
I would review the outsourcing contracts in force against the new regime: which providers are abroad, in which jurisdiction, and whether they can take on the audit commitment the BCRA now demands. That is where the most expensive surprises tend to show up.
And I would treat regulatory flexibility as a first-class architecture requirement, not an add-on. In a context where the rule changes every few months, building for today's compliance is building tomorrow's debt.
Modernizing the infrastructure of an Argentine financial institution is not a purely technical problem, nor a purely regulatory one: it means solving both at once, with the operation running and no room to stop. If your team is staring at the 180-day deadline and still doesn't have the map, at Renaiss we do cloud consulting for Argentine companies that operate under BCRA regulation. We wrote about how to approach these projects in migrating to cloud at an Argentine fintech and in core banking modernization.

‍