Argentina’s new fraud-prevention framework puts a practical question in front of banking technology teams: how should a shared risk signal change an individual payment decision? Connecting another data feed is only the beginning. The harder work is deciding who can act on that signal, how to handle uncertainty, and how to reconstruct a decision when a customer challenges it.
The BCRA’s September 3 announcement describes a gradual initiative in which instant-transfer administrators distribute fraud-risk profiles to banks and payment-account providers. It explicitly connects better monitoring with identifying unusual patterns involving illegal gambling. The stated objective is to supplement institutions’ existing analysis. That makes this an operational architecture story as much as a compliance story. BCRA announcement.
Read the implementation boundary precisely
Communication A 8473 specifies monthly files and an API for distributing scores. Institutions must use them in onboarding, transaction monitoring and periodic customer reviews, but cannot base decisions exclusively on the score. The rule preserves their responsibility and requires evidence of use.
Its rollout has separate clocks: administrators receive 120 calendar days from publication; institutions receive 60 days for onboarding and periodic review, and 90 for transaction monitoring, measured from delivery of the specified technical documentation. These are distinct triggers, not one universal September cutover. Teams should have compliance owners verify the applicable documentation receipt date before setting their implementation deadline.
The design proposals below are editorial analysis. They describe ways a team could operationalize that boundary; they are neither additional regulatory requirements nor a claim that every payment must invoke a remote model synchronously.
Design the signal contract before choosing a model
Treat a score as an observation with a lifecycle. A proposed internal record would carry an identity key, issuer, scoring version, observation time, effective time, retrieval time and freshness status. Preserve the distinction between an unavailable response and an actual low-risk result. Otherwise an outage can silently turn into apparent reassurance.
Consider a hypothetical customer whose score changes between opening an account and receiving a transfer. The onboarding record should retain the version that was actually consulted. The payment record should show its own evidence and policy version. Overwriting both records with the newest score destroys the ability to explain why the two decisions differed.
Make those semantics part of procurement. Ask an administrator or vendor how corrections propagate, how missing identities are represented, what historical versions remain available and how clients distinguish an unchanged value from a delayed refresh. A clean API schema is useful, but it cannot answer these questions by itself.
Separate the signal from the action
A useful proposed architecture has four components: a shared risk input, institution-specific context, an explicit decision policy and a review record. The policy combines the first two, selects an allowed response and records its basis. Depending on verified circumstances and applicable procedures, possible responses might include ordinary processing, additional authentication or referral for investigation.
The important implementation detail is that no individual score should secretly encode all those actions. If risk operations wants to change a threshold, the change should be visible as a policy revision with an owner and an effective date. If engineering replaces a model, the new model should not acquire broader action permissions automatically.
This also gives procurement a sharper acceptance criterion. A demonstration that ranks accounts correctly is different from a production system that handles an ambiguous identity, a customer appeal and a missing upstream response. Ask the supplier to demonstrate those complete workflows, using synthetic cases, before treating its benchmark as evidence that integration is finished.
Network evidence is promising, with a measurable boundary
The BIS Innovation Hub’s Project Hertha explored payment-system analytics as a supplement to bank and payment-provider monitoring. In its experiments, combining the system-level findings with institutional analysis identified 12% more illicit accounts; detection of previously unseen patterns improved by 26%. These are experimental findings, not expected production gains for Argentina.
The project report explains the boundary: the exercise used synthetic data representing 1.8 million accounts and 308 million transactions in a single jurisdiction. It did not use real customer data. Confirmed training cases, feedback from institutions and explainable outputs mattered to the results; practical deployment and regulatory questions remained outside the exercise’s scope.
For a LATAM buyer, the implication is to test the contribution of shared information separately from the contribution of a new algorithm. A vendor can improve an aggregate metric by changing several things at once. That does not reveal whether the benefit came from network visibility, better labels, a different threshold or the model itself. An acceptance test should hold those variables apart where possible.
Measure customer friction alongside detection
A fraud team can appear more effective simply by sending many more customers to review. Before a pilot, agree on the operating point: what additional loss detection is worth, how much review capacity exists and what delay legitimate customers can tolerate. Report outcomes by relevant operational segments rather than relying on one fleet-wide average.
NIST’s AI Risk Management Framework discussion of trustworthiness connects validity with realistic testing, false-positive and false-negative measurements, ongoing monitoring and contextual human judgment. It also treats privacy, explainability and accountability as interacting properties. This is voluntary framework guidance, not an Argentine legal obligation.
A practical pilot dashboard could pair confirmed detection with review turnaround, abandoned onboarding, successful appeals and decision reversals. Keep unconfirmed alerts separate from confirmed fraud. Where outcome labels arrive late, show that delay explicitly; yesterday’s unresolved cases should not become today’s proof of success merely because nobody has closed them.
Give failure paths an owner
For implementation planning, consider three failure drills. First, the score provider times out while transfers continue arriving. Second, a corrected upstream identity changes a previously elevated result. Third, a deployment produces a sudden increase in referrals without a corresponding increase in confirmed fraud. Each drill should end with an accountable decision and a recoverable record.
The team should define permissible fallback behavior for each workflow with its risk and compliance owners. A time-sensitive transfer and a periodic customer review may justify different handling. Measure fallback use separately, and make prolonged reliance visible. An emergency path that quietly becomes the normal path leaves everyone with misleading evidence about which controls actually operated.
For corrections, test whether the review team can find affected decisions without reconstructing them from application logs. A targeted correction workflow should preserve prior evidence, record the correction and support a fresh decision. Treating history as immutable evidence does not require treating every prior conclusion as permanently correct.
Buy an operating capability
The strongest business case should include the cost of integration, validation, investigations and customer support alongside the price of scoring. A nominally free input still consumes engineering and operational capacity. Assign ownership for the connector, decision policy, review process and performance evaluation before the first production milestone.
For teams elsewhere in Latin America, Argentina is a concrete case study, not a substitute for local requirements. The transferable design question is whether a shared signal can improve decisions while retaining institutional context, clear responsibility and a route to correct mistakes. The same architecture can support a statistical score or a machine-learning model; the choice should follow the evidence available for the intended use.
At the next steering meeting, ask for three artifacts: a decision record from a synthetic case, the results of an upstream-outage drill and a pilot scorecard that includes customer friction. Together they make progress reviewable. They also turn a broad promise of better fraud detection into specific capabilities that a bank or payment provider can operate, challenge and improve.