Guide

Fintech Regulation in Argentina

A 2026 Legal Guide for Fintech, Payments and Crypto Businesses

A practical legal overview for fintechs, payment companies, lenders, crypto and virtual-asset businesses, and foreign companies weighing entry into Argentina — mapping the BCRA, CNV and UIF perimeter, registrations, corporate setup and compliance.

Last updated: June 2026

Planning a fintech launch in Argentina?

Speak with our team

Introduction: Argentina as a Fintech Market

Argentina has one of the most active fintech markets in Latin America. Digital wallets are widely used, electronic transfers move a large share of everyday payments, crypto and stablecoin activity runs high, and the country has a deep bench of local talent in technology, law, finance and compliance.

Several things make the country attractive to foreign fintechs. It is a large consumer and business market and a real technology hub in South America, and financial innovation has spread quickly here, reaching payments, lending, crypto-assets, infrastructure software, open finance, merchant services and cross-border products.

It can also work as an entry point into the rest of Latin America. Some companies treat Argentina as a standalone market. Others use it as a regional talent base, a place to test a product, or a commercial bridge into neighboring markets.

It is not, however, a plug-and-play jurisdiction. What matters legally is what the product actually does, not the label the company gives itself. A digital wallet, a payment processor, a crypto exchange, a lending platform, an open-finance provider, a SaaS vendor, a remittance business, a card program or an acquiring model can each fall under a different set of rules.

For that reason, the place to start is not corporate structure. The first question is a simpler one: what regulated activity, if any, will the product perform in Argentina?

This guide is a practical legal overview for foreign fintechs weighing entry into Argentina. It walks through the main regulatory perimeters, including BCRA payment regulation, the CNV’s PSAV/VASP framework, UIF anti-money laundering obligations, consumer protection, data protection under Law No. 25,326 and the AAIP’s criteria, tax registration before ARCA, and the foreign-exchange rules. It then turns to the core fintech verticals: payment services and PSP registration, crypto-assets and PSAV/VASP registration, lending, open finance and financial infrastructure.

It is written for the people who actually have to make these decisions, founders, legal teams, CFOs, compliance officers, product leads, regional managers and investors trying to structure, register and launch a fintech product in Argentina.

It will be most useful to payment companies, wallets, crypto platforms, lenders, stablecoin and digital-asset businesses, SaaS providers to financial institutions, API and infrastructure providers, remittance and cross-border payment companies, and Asian fintech groups looking at Argentina or Latin America as their next market.

Key Takeaways

a.Argentina has no single fintech regulator and no single fintech license. Rules apply by activity, mainly through the BCRA, the CNV and the UIF, alongside consumer-protection, data-protection and tax authorities.
b.What matters legally is what the product actually does, not how it is labelled. The starting point is a regulatory perimeter analysis, not corporate structure.
c.Payment models (wallets, accounts, transfers, acquiring) typically engage the BCRA and PSP registration; crypto and virtual-asset services engage the CNV's PSAV registry; lending engages the PNFC / OPNFC framework.
d.AML/UIF obligations turn on the activity, and PSAVs are expressly regulated subjects. Even where a company is not directly obligated, banks and partners require AML readiness before onboarding.
e.Foreign fintechs usually operate through a local subsidiary (Article 123) or a branch (Article 118), with the corporate setup following the regulatory model rather than the other way around.

Main Argentine Fintech Regulatory Perimeters

Argentina has no single fintech regulator and no single fintech license. The framework that applies turns on what the company does, how the product is built, how money flows through it, who its customers are, and whether it touches regulated assets, financial services, payment accounts, securities, crypto-assets, personal data, consumers or cross-border flows.

A foreign fintech should therefore start with a regulatory perimeter analysis. In practical terms, that means working out which Argentine regulators may have jurisdiction over the product, and which registrations, approvals, disclosures, policies or operational requirements have to be in place before launch.

Central Bank / BCRA

The Banco Central de la República Argentina, the BCRA, is the main regulator for payment services, payment accounts, payment infrastructure and foreign-exchange matters.

The BCRA tends to come into play wherever a product involves payment accounts, digital wallets, fund transfers, payment initiation, acquiring, aggregation, merchant services, QR functionality, participation in interoperable payment schemes, payment processing, cash-in/cash-out networks, or any role in the national payment system.

The BCRA keeps a register of payment service providers and related payment-system participants. It covers payment account providers, payment initiators, acquirers, aggregators, acceptors of payments with transfer, ATM networks, transfer networks, and QR-related roles where they apply.

Depending on the model, a fintech may have to register before it operates, complete one registration before applying for another function, work through a registered local partner, or set up its Argentine activity as a technology or infrastructure service that does not itself perform regulated payment functions.

For foreign fintechs, the BCRA question is rarely about the label. What matters is the function, namely whether the company:

a.opens or administers payment accounts;
b.receives, holds, transfers or settles customer funds;
c.initiates payment orders;
d.acquires merchants or processes merchant payments;
e.aggregates merchants or payment flows;
f.participates in payment infrastructure;
g.provides wallet functionality;
h.provides QR payment functionality or participates in QR payment interoperability;
i.interacts with local payment rails; or
j.depends on local bank or PSP partners to operate.

The BCRA also matters for foreign-exchange purposes. Capital contributions, intercompany loans, cross-border payments, service fees, dividends, profit remittances and certain settlement structures may all need to be designed with Argentina’s FX rules in mind.

Securities Regulator / CNV

The Comisión Nacional de Valores, the CNV, regulates Argentina’s capital markets, and it is increasingly relevant to fintechs working with crypto-assets, tokenization, investment products, brokerage-like services, securities, collective investment products or capital markets infrastructure.

For crypto and digital-asset companies, the CNV matters because Argentina has built a registration framework for Proveedores de Servicios de Activos Virtuales, or PSAVs. These are the local equivalent of what most jurisdictions call Virtual Asset Service Providers, or VASPs.

The PSAV framework rests on Law No. 27,739, which amended Law No. 25,246 and brought in the local definition of virtual assets and virtual-asset service providers, and on CNV General Resolution No. 1058/2025, which sets out the current registration and conduct rules for PSAVs.

A foreign company may need to look at the CNV perimeter if it offers services involving:

a.exchange between virtual assets and fiat currency;
b.exchange between one or more forms of virtual assets;
c.transfer of virtual assets;
d.custody, administration or safekeeping of virtual assets;
e.participation in financial services related to the offer or sale of virtual assets;
f.tokenized investment products;
g.brokerage, dealing or intermediation involving securities or securities-like instruments; or
h.investment products marketed to Argentine users.

The CNV perimeter deserves a careful read where a product combines crypto, payments, yield, investment features, tokenized assets or access to financial instruments. A product marketed globally as crypto, Web3, tokenization or infrastructure can still pull in Argentine securities, PSAV or capital markets analysis.

Financial Information Unit / UIF

The Unidad de Información Financiera, the UIF, is Argentina’s anti-money laundering and counter-terrorist financing regulator.

Whether a fintech picks up AML obligations depends on what it does. The question is sharpest for PSAVs, crypto platforms, payment businesses, lending models, financial intermediaries and other companies that may land on Argentina’s list of regulated AML subjects.

PSAVs are named as regulated subjects under the AML framework, so crypto and digital-asset companies should work through their UIF obligations at the same time as CNV registration, not afterwards.

Where they apply, UIF obligations can include customer identification, beneficial ownership verification, risk-based customer due diligence, enhanced due diligence for higher-risk customers or jurisdictions, transaction monitoring, suspicious transaction reporting, recordkeeping, internal policies, appointment of a compliance officer, training and periodic reporting.

AML analysis also matters for a more practical reason. Even when a company is not clearly a regulated AML subject itself, banks, PSPs, custodians, acquirers and local partners will usually ask for solid AML/KYC documentation before they agree to onboard it.

That is especially true for cross-border payment, crypto, stablecoin, remittance, marketplace, lending and high-volume merchant models.

Consumer Protection Authorities

Fintech products offered to individuals in Argentina can trigger consumer protection obligations.

This applies to wallets, lending platforms, BNPL products, payment apps, crypto platforms, card programs, consumer-facing marketplaces, subscription products, financial apps and any digital service that charges fees or affects user funds.

Consumer protection issues may include:

a.clear disclosure of fees, charges and product conditions;
b.transparent terms and conditions;
c.complaint channels and customer support;
d.advertising and marketing claims;
e.unilateral modification of terms;
f.refund, cancellation or error-resolution mechanics;
g.treatment of vulnerable consumers;
h.digital contracting;
i.data and consent language; and
j.coordination between consumer terms and regulated financial obligations.

Foreign fintechs should not assume that a set of global terms and conditions can be translated into Spanish and used as-is. Consumer-facing documents need to be localized to reflect Argentine law, what local regulators expect, how payments actually work, the available complaint procedures, and the real operating model.

Data Protection / AAIP

Argentina’s personal data regime sits mainly in Law No. 25,326, with the Agencia de Acceso a la Información Pública, or AAIP, as the enforcement authority.

Fintechs usually handle sensitive commercial and personal data: identity documents, tax identifiers, bank account data, transaction history, device information, geolocation, fraud signals, credit information, biometric data or crypto-wallet information.

The data protection framework bears on privacy policies, data processing agreements, cross-border transfers, user consent, information security, vendor arrangements, cloud services, customer support, fraud prevention and group-level data sharing.

For foreign groups, this gets more important the moment infrastructure, compliance teams, data lakes, cloud services, customer support or risk engines sit outside Argentina.

Data protection should be looked at together with cybersecurity, outsourcing and operational-resilience obligations, particularly for payment companies, wallets, open-finance providers, API businesses and anyone integrated with banks, PSPs or other regulated entities.

Argentina has been weighing changes to its data protection regime, so the status of any reform should be checked before a policy is published or implemented.

Tax Authority / ARCA

The Agencia de Recaudación y Control Aduanero, or ARCA, comes into the picture once the company has a local taxable presence, an Argentine entity, a branch, employees, invoicing activity, withholding obligations, import or export activity, or other local tax obligations.

For market entry, ARCA matters because the company may need:

a.CUIT registration;
b.tax activity registration;
c.VAT and income tax registration;
d.local invoicing setup;
e.employer registration;
f.withholding or collection-agent analysis;
g.gross receipts tax analysis;
h.transfer pricing support for intercompany arrangements; and
i.documentation for cross-border payments, service fees, royalties or intercompany charges.

For a foreign fintech, tax and ARCA registration should move in step with the corporate structure and the operating model. The tax treatment can shift depending on whether the company sells cross-border, runs through a local subsidiary, uses a branch, contracts through a local partner, or provides services to other group companies.

Foreign Exchange Rules and BCRA FX Framework

Foreign-exchange planning is a core part of fintech market entry in Argentina.

Even a company that is not in the FX business should understand how Argentina’s FX rules can affect capital contributions, intercompany loans, cross-border service payments, dividends, branch profit remittances, offshore and local settlement, merchant payouts, stablecoin flows, and payments to foreign vendors or group companies.

The central question is how money moves:

a.who pays;
b.who receives;
c.where funds are held;
d.in which currency settlement occurs;
e.whether funds enter the Argentine foreign exchange market;
f.whether a local entity holds customer or merchant funds;
g.whether funds are converted between currencies;
h.whether intercompany charges or settlement accounts are involved; and
i.whether repatriation is expected.

For payment companies, remittance models, stablecoin platforms and cross-border infrastructure providers, FX analysis belongs in the product design from day one, not as a later fix.

The trap to avoid is launching with a commercial flow that works operationally but later creates tax, FX, banking, regulatory or repatriation problems. In Argentina, the legal structure, the payment flow and the FX treatment have to be designed together.

Because Argentina’s foreign-exchange framework has changed substantially since 2025 and may keep changing, any specific statement about access to the FX market, dividend payments, service payments or repatriation should be confirmed at the time of implementation.

Payment Services and PSP Registration

Payment services are one of the biggest fintech verticals in Argentina. Digital wallets, payment accounts, interoperable transfers, QR payments, merchant acquiring, payment initiation, aggregation, processing, cash-in/cash-out services and payment infrastructure can all trigger regulatory analysis.

For foreign payment companies, the regulator is usually the Banco Central de la República Argentina, the BCRA, which oversees payment service providers, payment accounts and participation in the national payment system. Depending on the product, a company may register with the BCRA directly, work through a registered local partner, or set up its Argentine activity as a technology or infrastructure service that does not itself perform regulated payment functions.

The first step is to map the product. Being called a “payments company” settles nothing; what counts is the specific function the company performs in the payment chain.

A foreign company should determine whether it will:

a.open or administer payment accounts;
b.receive or hold customer funds;
c.process debits and credits;
d.initiate payment instructions;
e.acquire merchants;
f.aggregate merchants or payment flows;
g.provide QR payment functionality or participate in QR payment interoperability;
h.connect to local payment rails;
i.provide wallet functionality;
j.settle funds to merchants or users;
k.provide technology to a regulated payment provider; or
l.act only as a foreign service provider without direct local payment activity.

The answers decide what comes next: BCRA registration, forming a local entity, onboarding a partner, adjusting contracts, AML review, cybersecurity obligations, consumer protection analysis or foreign-exchange planning.

What Is a PSP in Argentina?

Payment service providers are non-bank entities that carry out payment functions inside the payment system. They are not banks or financial institutions, but they can still face BCRA registration, operational rules, reporting obligations and user-protection requirements.

The BCRA framework recognizes several payment-service roles, among them payment account providers, payment initiators, acquirers, aggregators, acceptors of payments with transfer, ATM networks, transfer networks, and QR scheme or interoperability roles where they apply.

For many fintechs, the category that matters commercially is the provider of payment accounts, the PSPCP. A PSPCP can offer payment accounts that let users hold pesos of free availability and send or receive payments. This is the category at the heart of most digital wallet models.

Not every company that touches payments is a PSPCP, though. A business can be a merchant acquirer, payment initiator, processor, software vendor, aggregator, infrastructure provider, commercial partner or scheme participant without offering payment accounts at all.

This distinction is critical for foreign companies. Two products can look identical to the user yet be regulated very differently, depending on who holds the funds, who contracts with the user, who instructs transfers, who controls the account, who connects to the local payment system and who carries operational responsibility.

PSPCPs and Payment Accounts

A PSPCP is a payment service provider that offers payment accounts. These are not bank accounts, but they let users hold pesos and make or receive payments within the relevant scheme.

It is the category for digital wallets and for any platform that gives users a balance, payment functionality or account-like services.

A foreign fintech should look at PSPCP registration if its Argentine product will involve:

a.user balances in pesos;
b.payment accounts;
c.digital wallet functionality;
d.transfer functionality;
e.receipt of funds from users;
f.payment orders initiated by users;
g.merchant or user payouts;
h.local account identifiers or payment credentials;
i.integration with local payment rails; or
j.customer-facing payment services under the company’s own brand.

A PSPCP model raises plenty beyond the registration itself: safeguarding and segregation of customer funds, keeping those funds available to users, user terms and conditions, BCRA reporting, cybersecurity, fraud prevention, complaint handling, operational resilience, AML/KYC, consumer protection, and relationships with banks or infrastructure providers.

PSPCP analysis also has to be coordinated with corporate setup. The company may need an Argentine vehicle, local tax registration, ARCA access, a local bank or payment-infrastructure relationship, and governance that banks, regulators and counterparties will accept.

Payment Initiation, Processing, Acquiring and Merchant Services

Many foreign fintechs do not start with a wallet or payment-account model. They come in through merchant services, acquiring, payment initiation, processing, gateways, orchestration, fraud tools, QR technology or other infrastructure layers.

These models need careful classification, because the regulatory analysis turns on the exact function performed.

A company that only supplies technical processing or software to a regulated payment provider has a different regulatory profile from one that contracts directly with merchants, initiates payment instructions, receives funds, aggregates merchant payments or controls settlement.

It helps to separate the main models:

a.technology provider models, where the company provides software, APIs, fraud tools, orchestration, reconciliation or other infrastructure to a regulated or locally responsible entity;
b.merchant-facing models, where the company contracts directly with merchants or provides payment acceptance services;
c.payment initiation models, where the company initiates or transmits payment orders;
d.aggregation models, where the company groups merchants or payment flows under a single operational or contractual structure;
e.settlement models, where the company controls or participates in the movement of funds to users, merchants or counterparties;
f.QR interoperability or scheme-participation models, where the company participates in QR payment flows, interoperable transfer schemes or related payment-system roles; and
g.white-label models, where the customer-facing product may be offered under one brand while regulated functions are performed by another party.

The line matters because calling yourself a software provider does not make the regulatory question disappear. If the company controls funds, instructs payments, manages settlement or performs regulated payment functions, it will be judged on what it does.

The reverse is also true. A company that supplies technology to a properly regulated local partner can often enter with a lighter footprint, as long as the contracts, operational flows, data responsibilities and liability allocation are set up correctly.

Registration vs. License

Foreign companies often ask whether Argentina requires a “payment license.” It depends on the activity. For many payment-service models, what applies is a BCRA registration, not a full prudential banking license.

That distinction is real, but it should not be oversold. A registration can still carry serious obligations: ongoing reporting, operational requirements, cybersecurity controls, user-protection rules, regulatory scrutiny and limits on how the company can operate.

For market entry, the label matters less than the substance. The questions that actually decide the path are:

a.whether the company can legally launch before registration;
b.whether it needs a local Argentine entity;
c.whether it needs a local bank or PSP partner;
d.whether customer funds must be held or safeguarded in a specific way;
e.whether the company must file information with the BCRA;
f.whether the company must comply with cybersecurity or fraud-prevention rules;
g.whether AML/KYC obligations apply directly or indirectly;
h.whether consumer-facing disclosures and terms must be localized; and
i.whether the operating model will be acceptable to banks and payment infrastructure providers.

The word “registration” can lull foreign fintechs into thinking the job is simple. It isn’t. The real work is designing a compliant operating model.

Key PSP Requirements

The exact requirements depend on the PSP category and the product structure, but most PSP models call for analysis of:

a.local legal presence and corporate structure;
b.BCRA registration category;
c.user terms and conditions;
d.safeguarding and availability of customer funds;
e.bank or payment infrastructure relationships;
f.operational and cybersecurity controls;
g.fraud-prevention measures;
h.AML/KYC obligations, where applicable;
i.consumer protection and complaint procedures;
j.reporting obligations;
k.tax registration and invoicing;
l.data protection and outsourcing;
m.contractual allocation of liability with partners and vendors; and
n.FX treatment for cross-border flows.

PSP registration is not a filing you handle on its own. It belongs in a wider launch plan that covers entity setup, ARCA registration, banking, contracts, compliance, data, consumer terms and operational readiness.

The efficient sequence is usually to classify the model first, then decide whether to register directly, partner with a regulated local provider, or come in as a technology provider.

Safeguarding, Customer Funds and Operational Issues

How customer funds are handled is often the heart of a payment-services analysis.

For PSPCPs, Argentine regulation requires that 100% of customer funds be deposited, at all times, in sight accounts in pesos with financial institutions located in Argentina. The funds must be available the instant the customer asks for them, and the PSPCP’s systems must be able to identify and individualize each customer’s balance.

This is one of the tightest constraints on digital wallet and payment-account models. A PSPCP cannot treat customer balances as ordinary corporate treasury. Its structure has to keep the company’s own money separate from customer money, and its systems have to support individualization, availability and reconciliation.

Balances in payment accounts can be moved into Argentine money market mutual funds only at the customer’s express request, with the amount debited from the payment account. Any investment or yield feature therefore has to be built as something the customer actively chooses, not an automatic sweep of balances by the PSPCP.

This matters a great deal for foreign wallet providers. A global wallet model often assumes the company can centralize, sweep, invest or otherwise manage customer balances through a group treasury or an offshore settlement structure. For Argentine PSPCP activity, that assumption may simply not hold.

The company should therefore map:

a.where customer funds are held;
b.whether funds are held in Argentina;
c.whether funds are held in pesos;
d.whether funds are deposited in sight accounts with local financial institutions;
e.whether funds are segregated from the PSPCP’s own funds;
f.whether each customer’s funds can be identified and individualized;
g.whether users can access funds immediately upon request;
h.whether any investment feature requires express customer instruction;
i.whether the payment account is properly debited when funds are invested; and
j.whether the operating model can support reconciliation, auditability and regulatory reporting.

The economics of customer balances should also be checked at the time of implementation. Argentina’s rules on whether and how a PSPCP can keep or pass through the return earned on customer balances have shifted in recent years, so the current position needs to be confirmed when the product is structured.

On the merchant side, the company has to be clear on settlement timing, chargebacks and reversals, payment disputes, merchant reserves, fraud losses, refunds, reconciliation, and how liability is split among the company, merchants, acquiring partners, processors, banks and users.

It is also worth checking whether the global operating model relies on practices that do not travel well to Argentina. This comes up often with global wallets, cross-border merchant acquiring, stablecoin settlement, marketplace payouts, card programs and payment orchestration platforms.

Not sure which regulator applies to your product?

Whether you need BCRA, CNV or UIF registration depends on what your product actually does — how funds move, whether you hold custody, lend, or handle virtual assets.

Request a regulatory assessment

Crypto, Digital Assets and PSAV / VASP Registration

Argentina is one of the most important crypto and digital-asset markets in Latin America. Foreign crypto exchanges, wallet providers, custody platforms, stablecoin businesses, tokenization projects, brokerages and crypto-payment companies look at it for the same reasons: heavy user adoption, a sophisticated market, available talent and real demand for alternative financial infrastructure.

Crypto is no longer an unregulated space here. A crypto or virtual-asset business has to work out whether what it does falls within the framework for Proveedores de Servicios de Activos Virtuales, or PSAVs, broadly the local version of what many jurisdictions call a Virtual Asset Service Provider, or VASP.

The framework rests on two pillars: Law No. 27,739, which amended Law No. 25,246 to bring in the local definitions of virtual assets and virtual-asset service providers, and CNV General Resolution No. 1058/2025, which sets the operational registration and conduct rules that govern PSAVs today.

For foreign companies, using blockchain, digital assets or stablecoins is not what settles the question. What settles it is whether the company provides a regulated virtual-asset service in or from Argentina, or to Argentine users, in a way that triggers registration, AML/KYC, reporting, disclosure, operational or regulator-facing obligations.

When Crypto Businesses May Be Regulated in Argentina

A crypto or digital-asset company should test its product against the PSAV perimeter where it involves services such as:

a.exchange between virtual assets and fiat currency;
b.exchange between one or more forms of virtual assets;
c.transfer of virtual assets;
d.custody, administration or safekeeping of virtual assets;
e.participation in financial services related to the offer or sale of virtual assets;
f.crypto brokerage or intermediation;
g.wallet services involving control or administration of assets;
h.stablecoin-based payment or settlement flows;
i.tokenized investment or yield products;
j.digital-asset infrastructure offered to Argentine customers; or
k.crypto services marketed or made available to Argentine users.

Classification follows the actual service, not the language in the marketing. A company can call itself a platform, a wallet, a marketplace, an infrastructure provider, a software company, an exchange, a broker, an app, a protocol interface or a payment solution. Those labels are relevant, but none of them is decisive.

What the analysis looks at is who controls the user relationship, who has custody or control of the assets, who executes or routes transactions, who sets pricing, who provides exchange functionality, who holds the private keys or signing authority, who settles funds, who carries operational responsibility, and whether the service is offered to Argentine users.

CNV PSAV / VASP Perimeter

The CNV runs the PSAV registry and supervises registered PSAVs within its statutory perimeter.

The framework reaches companies that provide virtual-asset services in Argentina or to Argentine users. Registration is the first thing to check for crypto exchanges, custodians, brokers, platforms, transfer services, certain wallet models, and any business offering financial services tied to virtual assets.

Under CNV General Resolution No. 1058/2025, a company whose activity falls inside the PSAV perimeter should sort out registration before it starts operating. This is not a box-ticking step. It shapes how the company builds its local presence, its onboarding, its compliance framework, its customer disclosures, its AML/KYC program, its operational controls and its dealings with the regulator.

Before entering, a foreign company should check two things: whether its activities meet the PSAV definition, and, if it is a foreign legal entity, whether any of the CNV’s specific points of contact with Argentina apply. That check belongs before it offers services into Argentina, sets up local ramp or payment arrangements, uses an Argentine domain, advertises to Argentine residents, or operates through a local subsidiary or branch.

Registration analysis should run alongside a securities-law review. Products sold as tokens, digital assets, yield products, tokenized instruments, investment pools, revenue-sharing rights or structured crypto can raise questions well beyond PSAV registration, touching capital markets, public offering, securities, collective investment or investor protection.

Foreign VASPs Serving Argentine Users

Foreign VASPs should pay close attention to the rules for foreign legal entities that provide PSAV services in connection with Argentina.

Under CNV General Resolution No. 1058/2025, a company incorporated outside Argentina that itself performs one or more activities within the PSAV definition must register with the CNV before carrying them out, where those activities take place under any of the points of contact with Argentina the regulation sets out.

This is a central market-entry rule. The test is not some informal list of indicators; it is the specific set of triggers the CNV has written down.

A foreign legal entity may be treated as performing PSAV activities in Argentina where any of the following applies:

a.Use of an Argentine domain
b.Local collection or ramp arrangements
c.Clear targeting of Argentine residents
d.Advertising clearly directed to Argentine residents
e.Argentine business volume threshold

A foreign company caught by these rules should work out whether it has to register as a PSAV before it operates.

The regulation also sets out how a foreign company can operate. It can run PSAV activity through an Argentine company it owns, whether directly or through another company in the same group, registered under Article 123 of the General Companies Law. Or it can operate through a branch, seat or other permanent representation registered under Article 118 of the General Companies Law.

So a foreign VASP cannot treat Argentine access as a purely cross-border question. Once it is actively targeting Argentina, or otherwise falls within the CNV’s points of contact, the analysis has to cover both PSAV registration and the right local corporate structure.

Reverse solicitation matters, but it has to be handled with care. A foreign platform is not targeting Argentina just because an Argentine resident reaches out on their own. That position gets harder to defend, though, once the company runs Argentina-facing marketing, plugs into local payment rails, sets up local ramp arrangements, builds Argentina-specific onboarding, or does anything else that lands within the CNV’s listed points of contact.

When planning entry, a foreign VASP should be honest about which side of the line it is on: passive, customer-initiated access, or active entry under one of the CNV’s triggers.

Custody, Exchange, Brokerage and Transfer Models

Different digital-asset models raise different legal issues.

A custody model turns on whether the company holds, controls, administers or safeguards virtual assets for users. Private keys, wallet infrastructure, omnibus and segregated wallets, sub-custody, cold and hot storage, signing authority, insolvency treatment and user rights all need to be mapped carefully.

An exchange model brings in fiat-to-crypto, crypto-to-fiat and crypto-to-crypto functionality. The issues here are pricing, execution, order routing, spreads, liquidity providers, local payment integrations, settlement, user disclosures and AML controls.

A brokerage or intermediation model raises extra questions when the company sits between users and third-party exchanges, liquidity providers, custodians or other counterparties. The analysis has to pin down who faces the user, who executes the trade, who holds the assets, who carries the liability and how the economics are disclosed.

A transfer model turns on whether the company transmits, routes, facilitates or administers transfers of virtual assets. It is especially relevant for wallets, remittances, cross-border payments, stablecoin settlement and treasury products.

A technology or infrastructure model can carry a lighter footprint if the company only provides software, APIs, custody technology, wallet infrastructure, analytics, compliance tools or blockchain infrastructure to a regulated or responsible entity. But the contracts and the operating model have to back up that characterization.

These distinctions are not academic. They decide whether the company needs local registration, which AML/KYC framework applies, which contracts must be localized, which banking relationships are even possible, and how the product should be presented to users and counterparties.

AML/KYC and Sanctions Considerations

Crypto and digital-asset businesses sit at the sensitive end of the AML/KYC spectrum.

The UIF issued Resolution No. 49/2024 specifically for PSAVs. It sets minimum requirements for identifying, assessing, monitoring, managing and mitigating money laundering, terrorist financing and proliferation financing risk, takes a risk-based approach, and aims to keep PSAVs from being used by others for LA/FT/FP purposes.

A foreign crypto company entering Argentina should expect to address, at minimum:

a.customer identification and verification;
b.beneficial ownership checks;
c.risk scoring;
d.transaction monitoring;
e.enhanced due diligence for high-risk users, jurisdictions or activity patterns;
f.suspicious transaction reporting;
g.sanctions screening;
h.recordkeeping;
i.internal policies and controls;
j.compliance officer responsibilities;
k.training; and
l.regulator-facing readiness.

Even when a foreign company plans to work through a local partner, AML responsibility has to be allocated in the contracts and in the operations. Banks, PSPs, custodians, liquidity providers and regulated counterparties will usually want clear documentation of the customer base, product flow, ownership structure, source of funds, compliance policies and risk controls.

This bites hardest for Asian and cross-border groups built on multi-tier ownership chains, offshore holding structures, global liquidity providers, stablecoin rails, cross-border settlement, or customers spread across several jurisdictions.

Stablecoins and Crypto Payment Models

Stablecoins matter a lot in Argentina because people use them as a practical alternative for saving, settlement, treasury management, cross-border payments and access to dollar-linked value.

A foreign fintech using stablecoins in Argentina has to look at both the crypto perimeter and the payment perimeter. Depending on how it is built, a stablecoin product can raise PSAV, AML, consumer protection, FX, tax, payment-service or contractual questions.

Important questions include:

a.whether users can buy, sell, hold or transfer stablecoins;
b.whether the company provides custody or wallet functionality;
c.whether the stablecoin is used for merchant payments;
d.whether the product includes fiat on-ramps or off-ramps;
e.whether Argentine pesos are accepted or paid out;
f.whether the company or a partner controls settlement;
g.whether stablecoins are used for remittances or cross-border flows;
h.whether the product is marketed as savings, investment, payment or treasury infrastructure;
i.whether users are consumers or businesses; and
j.whether the company relies on local PSPs, banks, exchanges or liquidity providers.

Stablecoin payment products cannot be designed in a vacuum, separate from payment regulation. The same product may need testing against PSAV rules, BCRA payment rules, AML rules, consumer protection, FX regulation and tax.

Tokenization and Sandbox Opportunities

Tokenization has become one of the most active areas in Argentine fintech and capital markets, both commercially and on the regulatory side.

Projects involving tokenized securities, real-world assets, investment instruments, digital representations of financial products, or blockchain-based capital markets infrastructure can need CNV analysis that goes beyond ordinary PSAV registration.

Whether the asset sits on a blockchain is beside the point. What counts is the legal nature of the underlying instrument and the rights the token actually represents.

A tokenization project should start by asking what the token is actually linked to:

a.shares;
b.corporate bonds or other debt securities;
c.CEDEARs;
d.mutual fund units;
e.trust certificates;
f.asset-backed instruments;
g.contractual rights;
h.credit rights;
i.equity-like rights;
j.fund interests;
k.investment exposure;
l.commodities;
m.payment rights; or
n.another legally relevant asset.

Argentina has built a specific tokenization framework through CNV regulations. General Resolution No. 1069/2025 set up a regime, run inside a regulatory sandbox, for tokenizing certain publicly offered securities backed by real-world assets. General Resolution No. 1081/2025 then widened it to cover instruments such as shares, corporate bonds, CEDEARs and mutual fund units, and pushed the sandbox out to August 21, 2026. General Resolution No. 1087/2025 added a further stage.

This is especially relevant for foreign fintechs because the digital representations are meant to be traded through platforms or apps run by CNV-registered PSAVs. Tokenization therefore ties straight back into the PSAV perimeter covered above. For background, see our analysis of tokenization and digital assets in Argentina.

Depending on the structure, tokenization projects may involve:

a.PSAV registration or partnership with a registered PSAV;
b.public offering analysis;
c.securities-law review;
d.collective investment or fund regulation;
e.broker-dealer or placement-agent issues;
f.custody and transfer mechanics;
g.investor onboarding;
h.AML/KYC;
i.disclosure documents;
j.platform terms;
k.secondary-market restrictions;
l.technology-provider contracts; and
m.tax and FX issues.

Tokenization can be appealing for foreign fintechs: the local fintech scene is advanced, the market already knows digital assets, and the regulator is actively testing digital versions of capital markets instruments.

The sandbox, though, is temporary and still moving, not a settled regime. Its scope, deadlines, eligible instruments and operating conditions should be confirmed before a launch leans on them. The CNV has kept expanding and adjusting the regime in stages, and more changes may well follow.

Tokenization is best treated as its own workstream, separate from ordinary crypto exchange or wallet activity. A company already registered or analyzed as a PSAV can still need extra CNV, securities, contractual, tax, AML or investor-protection review, depending on the product.

Lending, Consumer Finance and Own-Capital Credit Products

A foreign fintech that plans to lend in Argentina with its own capital should look at the framework for Proveedores No Financieros de Crédito, or PNFCs.

This is one of the main categories for lending fintechs. You do not have to be a bank to fall inside the BCRA’s non-financial credit provider framework. What matters is whether the company, without holding a financial-institution license, offers credit to the public and lends on a habitual basis.

For fintech lenders using their own capital, the category is usually Otros Proveedores No Financieros de Crédito, or OPNFCs. It can apply to consumer loans, SME loans, merchant financing, BNPL-style financing, working-capital loans, digital credit products, payroll-related credit, invoice financing and other products funded from the company’s own capital or group resources.

Own-capital lending can be a workable way in for a foreign fintech. It is structurally different from deposit-taking, public fundraising, marketplace lending, securitization, crowdfunding or investment products tied to loan portfolios. That does not make it legally light. Before launch, the company should review OPNFC registration, consumer protection, financial-user rules, credit documentation, tax, FX, data protection, reporting, collection practices and enforceability.

PNFC and OPNFC: The Main Lending Perimeter

The BCRA’s PNFC framework covers non-financial companies that offer credit to the public on a habitual basis. It takes in different kinds of providers, including non-financial issuers of credit or purchase cards and other non-financial credit providers, generally called OPNFCs.

For a foreign fintech coming in with an own-capital lending model, OPNFC is usually the first category to check.

A company should look at OPNFC registration where it:

a.grants loans to individuals, SMEs, merchants or companies;
b.offers credit through a website, app or digital platform;
c.finances the purchase of goods or services;
d.grants credit without a specific destination;
e.provides merchant financing;
f.offers BNPL-like financing;
g.grants working-capital loans to SMEs;
h.offers payroll, salary-advance or employee credit products;
i.grants financing habitually, even if lending is not its only business line; or
j.funds loans with its own equity, parent-company funds, intercompany financing, institutional credit lines or group treasury.

Using its own capital does not, on its own, take a lender out of the PNFC/OPNFC framework.

When Registration with the BCRA May Be Required

Whether OPNFC registration applies depends on the lender and on the size and nature of its credit activity. Work it out before launch, especially where credit will be offered to the public through a digital channel.

For foreign lenders, the registration analysis should weigh:

a.whether the company will lend through an Argentine subsidiary;
b.whether the lender will offer credit to the public in Argentina;
c.whether lending will be habitual;
d.whether the borrower base includes consumers, SMEs, merchants or corporate borrowers;
e.whether the company exceeds applicable portfolio thresholds;
f.whether the company will seek financing from Argentine financial institutions;
g.whether the product involves credit cards, purchase cards or card-linked financing;
h.whether the company will report borrower information to local systems;
i.whether the company needs bank, PSP or payment-rail onboarding; and
j.whether banks, PSPs, investors or regulators will expect a registered local credit-provider profile.

The registry is the Registro de Otros Proveedores No Financieros de Crédito, run within the BCRA framework and supervised by the Superintendencia de Entidades Financieras y Cambiarias. ARCA is not the substantive authority here; its portal and fiscal key are just the way you authenticate and get into the relevant BCRA service to start the filing.

In practice you reach the process online through ARCA, using the service “BCRA – Proveedores No Financieros de Crédito – Registro de Proveedores No Financieros de Crédito” and a clave fiscal at level 3. Have the CUIT, corporate documents, legal representative, fiscal access and the responsible internal staff lined up before you start.

Registration is not a banking license. An OPNFC is not a bank, and registering as a non-financial credit provider does not turn it into a financial institution. The framework is mainly about registration, information and reporting for non-financial credit activity.

Own-Capital Lending vs. Financial Intermediation

A core structuring question is whether the fintech lends with its own capital or intermediates third-party funds.

In an own-capital lending model, the lender funds loans from its own equity, parent-company funding, intercompany loans, retained earnings, institutional financing or group treasury. It carries the credit risk and contracts directly with the borrower.

That is a different animal from models where the fintech raises money from outside investors, pools funds, offers returns tied to loan performance, sells participation interests in loans, tokenizes credit rights, securitizes portfolios, sets up a trust or fund, or runs a marketplace between lenders and borrowers.

Those structures can pull in extra analysis under capital markets, public offering, securities, crowdfunding, trust, securitization, fund management, broker-dealer or financial intermediation rules.

For a foreign lender after a more direct route in, the usual starting point is:

a.an Argentine operating structure, where required;
b.own-capital or group-funded lending;
c.OPNFC registration analysis;
d.Argentine-law credit documentation;
e.consumer-protection and financial-user compliance;
f.tax and FX structuring of the funding flow; and
g.reporting systems compatible with BCRA requirements, where applicable.

Interest Rates, Fees and Total Cost of Credit

For ordinary own-capital loans made by OPNFCs, Argentina sets no single statutory ceiling on the interest rate and no BCRA nominal cap that applies to every loan.

This is a point foreign lenders often get wrong. The OPNFC regime is not a price-control regime for ordinary non-financial loans. The BCRA framework is built around registration, information, reporting and transparency, and as a rule it does not fix a maximum rate for ordinary OPNFC products.

So on a standard own-capital loan from a non-financial lender, the parties can agree the rate, fees and repayment terms, within the general limits of the law.

Those limits are not a fixed percentage written into a statute. They come mainly from:

a.general contract law;
b.the Civil and Commercial Code rules on judicial reduction of excessive interest;
c.consumer protection law, where the borrower is a consumer;
d.financial-user, transparency and claims rules, where applicable;
e.the criminal-law prohibition of usury; and
f.special regimes applicable to specific products, such as credit cards or purchase cards.

A fintech lender should therefore separate ordinary OPNFC lending from card-linked or special-regime financing. The fact that certain rules apply to non-bank credit card financing does not mean every OPNFC loan carries the same rate cap.

Judicial Review of Interest

Even with no fixed legal cap, a court can still review the interest.

Under Article 771 of the Civil and Commercial Code, a judge can cut the interest where the agreed rate, or the effect of capitalizing interest, exceeds, without justification and disproportionately, the average cost of money for similar debtors and transactions in the place where the obligation was taken on.

If excess interest has already been paid, it goes first against principal, and once principal is gone, the borrower can recover the rest.

This is an ex post control. It does not set a numeric ceiling for OPNFC loans; it lets courts trim interest that is unjustified and disproportionate on the facts of the case.

The practical takeaway for foreign lenders is that pricing has to be defensible, commercially and legally. The lender should be able to explain its rate by reference to the product, the borrower profile, credit risk, term, inflation, funding cost, default risk, operating cost and comparable market conditions.

Usury

The offense is not set by a percentage. It is about conduct. The statute punishes anyone who, exploiting another person’s need, carelessness or inexperience, gets them to give or promise interest or other financial advantages that are clearly disproportionate to what the lender provides, or to hand over extortionate security or guarantees.

The same article also reaches anyone who knowingly acquires, transfers or enforces a usurious credit, and penalties rise where the offender lends usuriously as a profession or by habit.

So a high rate is not, by itself, a crime. Criminal usury needs an exploitative situation plus terms that are clearly disproportionate, or extortionate guarantees. Even so, high-cost products aimed at vulnerable borrowers deserve a careful look, particularly where they involve aggressive refinancing, heavy penalties, opaque fees, abusive collection or disproportionate security.

This means that a high interest rate is not automatically a criminal offense. Criminal usury requires an exploitative situation and evidently disproportionate economic terms or extortive guarantees. However, high-cost credit products targeted at vulnerable borrowers should be reviewed carefully, especially where the product includes aggressive refinancing, excessive penalties, opaque fees, abusive collection practices or disproportionate security.

Consumer Credit and Total Cost Disclosure

Where the borrower is a consumer, the nominal rate is only part of it. The analysis also has to look at the total cost of credit and how clearly it is disclosed.

The lender should clearly disclose, as applicable:

a.nominal annual interest rate;
b.effective annual interest rate, where used;
c.total financial cost;
d.origination fees;
e.service fees;
f.platform fees;
g.taxes;
h.insurance or ancillary charges;
i.late interest;
j.penalties;
k.collection costs;
l.refinancing charges;
m.prepayment effects; and
n.any merchant subsidy, discount or embedded financing component.

A product can be legally risky even with no rate cap in play. The risk tends to come from unclear disclosure, misleading ads, thin cost information, abusive clauses, disproportionate late charges, aggressive collection, or a total financial cost that is presented inconsistently.

Practical Rule for OPNFC Lenders

For ordinary OPNFC lending, “what is the statutory maximum rate?” is the wrong question, because there generally is no single statutory maximum nominal rate for ordinary loans by non-financial lenders.

The questions worth asking are:

a.Is the product ordinary own-capital lending, or does a special regime apply?
b.Are the rate, fees and total cost properly disclosed?
c.Is the pricing defensible against judicial moderation?
d.Does the product create usury or consumer-protection risk?

The bottom line for a foreign lender: Argentina does not generally cap the nominal rate of ordinary OPNFC loans, but the pricing still has to be transparent, contractually valid, defensible and clear of usury or abusive-practice risk.

Consumer Protection, Financial-User Protection, Transparency and Claims

A lending fintech that offers credit to consumers has to meet the applicable consumer protection and BCRA financial-user standards.

For OPNFCs, the BCRA regimes in play, where they apply, include Protección de los usuarios de servicios financieros, Transparencia and Reclamos. They govern borrower-facing disclosures, customer service, complaint handling, information duties, how users are treated, contractual transparency, and how financial products are communicated and run.

Borrower-facing documents should spell out the economics from the start: the amount financed, the repayment schedule, interest, fees, total cost, what happens on default, how to repay, and how to complain.

The legal review should cover:

a.pre-contractual information;
b.digital acceptance mechanics;
c.borrower disclosures;
d.loan agreement content;
e.repayment schedule;
f.total cost of credit;
g.complaint channels;
h.customer service;
i.treatment of late payments;
j.refinancing or restructuring mechanics;
k.data used for scoring;
l.authorization for debit or repayment mechanisms;
m.collection practices;
n.advertising claims; and
o.recordkeeping.

It is most acute for app-based loans, BNPL products, payroll-linked products, revolving credit, consumer merchant financing and short-term loans.

Information Reporting and Central de Deudores

Registering as a PNFC/OPNFC is not a one-and-done filing. Registered providers can carry ongoing reporting obligations to the BCRA.

The framework requires registered non-financial credit providers to report on the financing they extend. That information can feed into the wider credit-information system, including the Central de Deudores del Sistema Financiero.

For a foreign lender, that has a few practical consequences:

a.loan data must be structured so it can be reported correctly;
b.borrower identification must be reliable;
c.credit balances, arrears and classifications must be tracked;
d.internal systems should support regulatory reporting;
e.the company must maintain accurate records;
f.data protection rules must be respected; and
g.responsibility for the accuracy of reported information must be assigned internally.

This weighs most on digital lenders with high volume, automated origination, short-term loans, consumer portfolios or merchant-credit products.

Funding the Argentine Lending Operation

A foreign fintech lending with its own capital has to decide how the Argentine loan book will be funded.

Common structures include:

a.capital contributions to an Argentine subsidiary;
b.intercompany loans from the foreign parent or group companies;
c.institutional credit lines;
d.local bank financing;
e.assignment or sale of receivables;
f.securitization or trust structures;
g.retained earnings; or
h.a combination of these alternatives.

Each option has tax, FX, accounting, corporate and regulatory consequences.

Capital contributions can strengthen the local balance sheet, but getting the money back out later usually runs through dividends or another lawful route. Intercompany loans give more flexibility, but they need documentation, transfer-pricing support, withholding-tax analysis and FX planning. Assignment, securitization or trust structures can help finance a portfolio, but they may pull in CNV, tax, trust, public offering or capital markets analysis.

Design the funding structure before origination starts. Otherwise the company can end up with a portfolio that is hard to finance, sell, assign, securitize or repatriate cleanly.

Interaction with Payment, AML, Data and FX Rules

A lending fintech can pull in extra regulatory analysis once the credit product connects to payments, AML-sensitive activity, data-driven scoring or cross-border flows.

That tends to happen where the model involves:

a.disbursement through payment accounts or wallets;
b.automatic debit or payment initiation;
c.repayment through PSPs, cards or payroll flows;
d.merchant acquiring or settlement;
e.credit cards or purchase cards;
f.crypto or stablecoin funding or repayment;
g.cross-border disbursement or repayment flows;
h.foreign funding of the local loan book;
i.large-scale consumer onboarding;
j.automated scoring or alternative data;
k.high-risk customer segments; or
l.partnerships with banks, PSPs, employers, merchants or marketplaces.

When it does, the OPNFC analysis has to be lined up with BCRA payment rules, UIF/AML, data protection, consumer protection, tax, FX and the contract documentation.

Practical Legal Entry Path for Foreign Own-Capital Lenders

A foreign fintech lending in Argentina with its own capital will usually need to work through these legal workstreams:

a.Local operating structure
b.OPNFC registration analysis
c.Funding structure
d.Loan documentation
e.Interest-rate and fee review
f.Consumer protection, transparency and claims
g.Reporting systems
h.Tax and FX review
i.Data and credit information

So for own-capital lenders the question is bigger than whether lending is allowed. It is whether the lender can come into Argentina with a structure that satisfies OPNFC registration, pricing disclosure, tax, FX, reporting and operational requirements, and still ends up with an enforceable credit product.

Open Finance, APIs and Financial Infrastructure

Open finance is becoming a bigger part of how Argentina regulates fintech. For foreign companies, it opens up room in credit, account aggregation, financial-data analytics, underwriting, fraud prevention, personal financial management, embedded finance, API infrastructure and bank-fintech partnerships.

Argentina set up the Sistema de Finanzas Abiertas through Decree No. 353/2025. The idea is to let individuals and companies share their financial information, with express consent, with entities registered before the BCRA, so as to widen access to credit, sharpen competition and support financial inclusion.

The key point for foreign fintechs is that open finance is not a free pass out of regulation. A company that takes part in it, provides APIs, processes financial data or supplies infrastructure to banks and fintechs still has to work out its actual role in the chain.

The analysis turns on whether the company:

a.only provides technology;
b.accesses or processes customer data;
c.receives data directly from users or from regulated entities;
d.initiates payments or other transactions;
e.offers credit scoring, underwriting or risk tools;
f.provides services to banks, PSPs, OPNFCs, PSAVs or other regulated entities;
g.contracts directly with consumers or businesses;
h.stores or transfers data outside Argentina;
i.uses data to make or support credit decisions; or
j.becomes part of a regulated financial, payment, lending or crypto product.

Argentina’s Open Finance Framework

The Sistema de Finanzas Abiertas is a general framework for sharing financial data on the basis of user consent.

It matters because it formally recognizes financial-data sharing and puts the BCRA in charge of setting the parameters, standards and requirements for participants.

For now, foreign fintechs should treat Argentine open finance as a regime still under construction. Creating the system mattered, but the operational detail depends on the specific rules, technical standards, security requirements, consent mechanics, participant obligations and timeline the BCRA and other authorities still have to set.

So an open finance project should not be judged on the decree alone. The company should confirm:

a.whether the BCRA has issued applicable implementing rules;
b.which entities may participate;
c.what type of information can be shared;
d.how consent must be obtained and documented;
e.what technical standards apply;
f.what security requirements apply;
g.whether third-party providers must register or meet eligibility conditions;
h.what liability rules apply between data providers, data recipients and users;
i.whether data can be used for credit, scoring, fraud, marketing or other purposes; and
j.whether additional sector-specific regimes apply.

For market entry, the question that matters most is simple to state: is the fintech just supplying technology to a regulated participant, or is it itself performing a regulated financial, payment, credit, data-processing or customer-facing activity?

Foreign fintechs should assume that any financial-data sharing rests on clear, express, well-documented customer authorization. The company should be able to show what the customer authorized, for what purpose, with whom, for how long, and how they can revoke it.

The consent setup should be reviewed alongside:

The consent architecture should be reviewed together with:

a.privacy policies;
b.data protection notices;
c.terms and conditions;
d.customer onboarding flows;
e.API access terms;
f.bank or PSP partner agreements;
g.vendor and processor agreements;
h.cybersecurity controls;
i.audit logs;
j.data retention policies; and
k.revocation and deletion procedures.

It comes to a head where the fintech uses data for credit scoring, underwriting, fraud prevention, risk segmentation, profiling, product recommendations or automated decisioning.

A fintech should also keep two things apart: consent to access data, and authorization to act on it. Pulling account information, receiving financial data, initiating a payment, opening a credit product, sharing data with affiliates, or using data for automated scoring can each call for different legal treatment and different disclosures.

Technology Provider vs. Regulated Financial Activity

Many foreign fintechs come into Argentina as technology providers to banks, PSPs, lenders, wallets, crypto platforms or other regulated entities.

That model can carry a lighter footprint if the foreign company only supplies software, APIs, data infrastructure, analytics, fraud and compliance tools, cloud services, orchestration, interface technology or back-end support, and does not itself perform the regulated activity.

But the technology-provider label has to match how the company actually operates.

A company that calls itself a technology provider can still need regulatory analysis if it:

a.controls the customer relationship;
b.makes or materially influences credit decisions;
c.initiates payment instructions;
d.holds or controls customer funds;
e.accesses payment accounts directly;
f.processes regulated financial instructions;
g.provides wallet or account functionality;
h.controls pricing or transaction execution;
i.has direct contractual relationships with end users;
j.performs onboarding or KYC as principal;
k.receives transaction-based compensation tied to regulated activity;
l.markets the regulated product under its own brand; or
m.assumes operational responsibility for a regulated financial service.

The line matters because a lot of fintech infrastructure sits right next to regulated activity. API providers, BaaS vendors, embedded-finance platforms, lending-infrastructure companies, fraud vendors, compliance tools and payment orchestration platforms can be unregulated in one configuration and regulated, or indirectly constrained, in another.

So the legal work has to name names: which entity performs the regulated function, which one contracts with the customer, which one holds the liability, which one answers to the regulator, and which one controls the data, the funds or the transaction flow.

APIs, Bank Partnerships and Regulated Counterparties

Foreign fintechs often get into Argentina by serving local banks, PSPs, OPNFCs, PSAVs, acquirers, aggregators, lenders, insurers or other regulated or semi-regulated counterparties.

There, the main legal instrument is usually a B2B agreement that splits responsibility for technology, data, security, customer communications, regulatory cooperation, audit, outsourcing, operational continuity and liability.

Contracts with regulated counterparties should typically address:

a.scope of services;
b.API access and availability;
c.service levels;
d.data ownership and permitted use;
e.confidentiality;
f.cybersecurity;
g.incident notification;
h.audit rights;
i.subcontracting;
j.outsourcing controls;
k.business continuity;
l.disaster recovery;
m.regulatory cooperation;
n.recordkeeping;
o.customer complaints;
p.indemnities;
q.limitation of liability;
r.termination assistance; and
s.post-termination data handling.

Where the local counterparty answers to the BCRA, CNV, UIF or another authority, the contract should mirror those obligations. A foreign technology provider may not be regulated the way its Argentine customer is, but it can end up contractually bound to standards that let the customer meet its own obligations.

A foreign API provider serving a bank or PSP, for instance, may have to meet cybersecurity, auditability, data-localization or outsourcing requirements that reach it indirectly through the regulated customer.

Data Protection, Cross-Border Transfers and Infrastructure Outside Argentina

Open finance and API models usually involve heavy data processing.

Argentina’s data regime, mainly Law No. 25,326, comes into play whenever the company collects, processes, stores, transfers or analyzes personal data. It bears especially on identity data, account data, transaction history, credit data, device information, fraud signals, biometrics, geolocation, employment information, merchant data and crypto-related data.

Cross-border transfers deserve particular attention from foreign groups. A lot of global fintechs keep cloud infrastructure, fraud engines, data lakes, analytics teams, customer support, compliance tooling and risk systems outside Argentina.

The legal review should identify:

a.what data is collected;
b.whether the data is personal, financial, sensitive or credit-related;
c.where the data is stored;
d.which affiliates or vendors access the data;
e.whether data is transferred outside Argentina;
f.whether the destination jurisdiction provides adequate protection;
g.whether contractual safeguards are required;
h.whether customer consent or notice is needed;
i.how long the data is retained;
j.how users can exercise data rights; and
k.how incidents must be handled.

Do this before integrating with banks, PSPs, lenders or open finance participants. Data architecture is hard to unwind after launch once the product is already built around centralized offshore infrastructure.

Cybersecurity, Operational Resilience and Outsourcing

Open finance, API and infrastructure models need a serious cybersecurity and operational-resilience review.

The analysis has to go past data protection to cover continuity of service, incident response, auditability, access controls, encryption, authentication, vendor risk, logging, monitoring and regulatory cooperation.

For foreign infrastructure providers, this bites hardest where the company supports:

a.banks;
b.PSPs;
c.wallets;
d.payment processors;
e.OPNFCs;
f.PSAVs;
g.credit platforms;
h.fraud-prevention tools;
i.KYC or AML systems;
j.account aggregation;
k.payment initiation; or
l.mission-critical financial infrastructure.

Regulated counterparties may hold the provider to technical, security and operational standards well beyond an ordinary SaaS contract. The customer may need audit rights, regulator-access clauses, subcontractor controls, data-location disclosures, incident-notification deadlines, business-continuity plans and termination-assistance obligations.

Review these before signing local B2B agreements. A global SaaS or API contract may not be enough for Argentine regulated financial clients.

Practical Legal Entry Path for Open Finance and API Providers

A foreign fintech entering Argentina through open finance, APIs or financial infrastructure should usually complete the following legal workstreams:

a.Regulatory perimeter analysis
b.Open finance status review
c.Data protection review
d.B2B contract localization
e.Cybersecurity and operational-resilience review
f.Customer authorization framework
g.Coordination with other regimes

The practical question is not whether Argentina has an open finance framework; it does. It is whether the company’s role in the data, payment, credit or infrastructure chain triggers direct regulation, indirect requirements through a regulated customer, or both.

Corporate Setup for Foreign Fintechs

If you are setting up locally, this guide pairs with our Doing Business in Argentina guide, which covers the full corporate, tax and foreign-exchange picture for foreign companies.

Corporate setup is not where a fintech market-entry analysis starts. The first step is to classify the product and pin down the regulatory perimeter. Only then should the company decide whether it needs a local entity, which kind, and how that structure has to mesh with regulatory, tax, banking, payment, AML and operational requirements.

This section is a fintech-specific summary. For the fuller treatment of entity formation, branch registration, SRL versus SA, CUIT, ARCA, timelines, costs and foreign-investment considerations, see our broader Doing Business in Argentina: Legal Guide for Foreign Companies.

When a Foreign Fintech May Need a Local Entity

A foreign fintech may need, or simply prefer, a local Argentine entity once the business involves local regulated activity, local customers or contracts, employees, local bank accounts, payment infrastructure, tax registration, borrower-facing lending, or PSP, OPNFC or PSAV registration.

A local entity tends to make sense where the company intends to:

a.register as a PSP or other BCRA-regulated payment participant;
b.register or operate as an OPNFC for own-capital lending;
c.register as a PSAV or operate through a structure contemplated by the CNV;
d.open local bank accounts or payment accounts;
e.contract with Argentine customers, merchants, borrowers or users;
f.enter into local bank, PSP, acquirer, processor or infrastructure agreements;
g.hire local employees or appoint local officers;
h.issue local invoices;
i.manage tax registrations before ARCA;
j.maintain local compliance or customer-support functions; or
k.create a clearer liability and accounting perimeter for Argentine operations.

A foreign fintech can start out through a cross-border, technology-provider, partnership, EOR, contractor or pilot setup. But once it performs regulated functions or builds a sustained Argentine-facing operation, a local corporate structure usually becomes either necessary or the commercially smarter choice.

The most common route, and usually the better one, is to register the foreign parent under Article 123 of the General Companies Law and then incorporate or take part in a local Argentine subsidiary. For a business that needs local banking, regulatory filings, customer-facing contracts, employees, payment infrastructure or a separate Argentine liability perimeter, that is generally more workable than running through a branch.

Recommended Vehicle: Local Subsidiary through Article 123

For most foreign fintech groups, the preferred structure will be:

a.registration of the foreign parent or relevant group company under Article 123 of the General Companies Law; and
b.incorporation or participation in an Argentine subsidiary, usually structured as an SRL or SA.

This lets the foreign company own the Argentine operating entity while keeping a separate local legal perimeter. It is also easier to put in front of banks, PSPs, acquirers, regulators, customers, employees and commercial counterparties than a purely cross-border model or a branch.

For fintechs, it is often the better structure where the company needs:

a.BCRA registration;
b.CNV/PSAV registration;
c.OPNFC registration;
d.local bank accounts;
e.local PSP, acquiring, custody or payment infrastructure relationships;
f.local contracts with customers, merchants or borrowers;
g.local invoicing and tax registration;
h.local employees or officers;
i.local AML, compliance or customer-support functions; or
j.clear separation between the Argentine operation and the foreign parent.

The Article 123 route also suits foreign groups with regional holding structures, Asian parents, U.S. or Cayman holding vehicles, Singapore or Hong Kong regional entities, or other multi-jurisdictional ownership chains.

SRL vs. SA for Fintech Subsidiaries

For most foreign fintechs setting up a local subsidiary, the practical choice comes down to a Sociedad de Responsabilidad Limitada, or SRL, and a Sociedad Anónima, or SA.

An SRL works well as the operating vehicle for a foreign-owned fintech subsidiary, especially where ownership is stable and the company does not need a share-based capital structure. It suits local operating subsidiaries, services companies, software providers, technology vendors, credit companies, payment-support entities, OPNFC lenders and other fintechs that want a solid but fairly simple local vehicle.

An SA may be the better fit where the company needs a share-based structure, more formal governance, broader shareholder flexibility, an institutional look, or where a regulator, bank, investor, partner or internal group policy expects one.

The choice is more than a formality. For fintechs, the entity type can affect bank onboarding, regulatory filings, governance documentation, director or manager appointments, corporate books, compliance evidence, signing authority and how local partners read the company.

As a practical matter:

a.SRL is often attractive for stable, foreign-owned operating subsidiaries;
b.SA may be preferable for more formal, regulated, institutional or share-based structures;
c.SAU is generally not the default recommendation for foreign fintechs, even if legally available, because it may carry additional compliance implications and is often less practical than a standard SRL or SA structure; and
d.SAS should generally not be selected as the default vehicle for foreign fintech operations, especially where the business will require regulatory registration, bank onboarding, PSAV registration, PSP activity, OPNFC activity or other institutional review.

SAS Is Generally Not Recommended for Regulated Fintechs

The Sociedad por Acciones Simplificada, or SAS, can be handy for simple entrepreneurial projects, but it is generally not the vehicle we would recommend for a foreign fintech entering Argentina.

It is not just about how fast you can incorporate. For regulated or banking-heavy fintechs, the real questions are regulatory eligibility, bank onboarding, how counterparties see you, governance, corporate documentation, AML review, beneficial ownership, long-term scalability and acceptance by regulators and financial institutions.

This is especially true for PSAVs. Under the current CNV framework, a local entity seeking PSAV registration is contemplated as an SA or SRL, while a foreign entity can operate through an Article 118 registration or take part in a local company through Article 123. So a SAS should not be the default vehicle for a PSAV structure.

For PSP and OPNFC structures, confirm the position under the BCRA rules in force at the time of filing. Even where the relevant BCRA text does not bar a SAS outright, a foreign fintech should still ask whether a SAS is the right call from a regulatory, banking and institutional point of view.

As a rule of thumb, foreign fintechs should look at an SRL or SA first.

Article 123 Registration of Foreign Shareholders

If the foreign parent is going to incorporate or hold equity in an Argentine subsidiary, it will generally have to register under Article 123 of the General Companies Law.

That registration lets the foreign company hold shares or quotas in a local Argentine company. For fintech groups, it usually comes up where the Argentine entity will be a subsidiary owned by a foreign holding company, a regional vehicle, the parent or another group company.

The Article 123 process generally calls for foreign corporate documents, proof of existence and good standing, constitutional documents, corporate approvals, a local representative, beneficial-ownership information, apostille or legalization, and sworn translation into Spanish where needed.

For fintech groups, the Article 123 filing should be coordinated with:

a.regulatory registration strategy;
b.beneficial ownership disclosures;
c.AML and bank onboarding;
d.corporate authority for local filings;
e.tax and funding structure;
f.intercompany agreements;
g.local representative appointments; and
h.timing for BCRA, CNV, UIF or other filings.

Where the ownership chain runs through multiple jurisdictions, offshore vehicles, regional holding companies, or entities from places that draw enhanced AML or tax scrutiny, expect to provide extra documentation or sit through additional review.

Branch Registration under Article 118

A foreign fintech can also register a branch, agency or permanent representation in Argentina under Article 118 of the General Companies Law.

A branch is not a separate legal entity. It is an extension of the foreign company, registered to operate in Argentina, and the parent stays directly liable for the branch’s obligations.

For fintechs, a branch can fit in particular cases, but it is usually not the default we would recommend for long-term Argentine operations.

A branch is worth considering where the foreign company wants to operate directly, where contractual or regulatory continuity with the parent matters, or where the model does not need a separate Argentine liability perimeter.

For most foreign fintechs, though, a local subsidiary through Article 123 is the more practical answer, especially where the business needs local bank accounts, customer-facing contracts, employees, regulatory and tax registration, local governance, and a cleaner separation between the Argentine operation and the parent.

Article 118 versus Article 123 should be decided together with the product’s regulatory classification and operating model. As a general steer, look at Article 123 and a local subsidiary first, and reach for Article 118 only where there is a specific legal, regulatory or commercial reason.

CUIT, ARCA and Tax Activation

Once it is incorporated or registered as a branch, the Argentine entity has to obtain a CUIT and complete tax registration before ARCA.

This is a gating item. Without a CUIT and active fiscal access, the company generally cannot issue local invoices, finish tax onboarding, register for the relevant taxes, complete local bank-account onboarding, hire employees, or deal fully with local administrative systems.

For fintech companies, CUIT and ARCA registration may also be relevant for:

a.BCRA filings;
b.CNV or PSAV-related documentation;
c.OPNFC registration;
d.bank and PSP onboarding;
e.local invoicing;
f.withholding-tax analysis;
g.employer registration;
h.accounting and reporting;
i.intercompany payments; and
j.local contract execution.

The broader Doing Business guide goes into CUIT, ARCA registration, fiscal-key access, expected timing and the implementation detail.

Bank Account Opening and Onboarding

Bank onboarding is often one of the most important practical hurdles for a foreign fintech.

Even with the legal structure right, local banks, PSPs, acquirers, custodians, liquidity providers or regulated partners may ask for enhanced documentation before they onboard the company.

For fintechs, onboarding review may focus on:

a.ownership structure;
b.beneficial owners;
c.source of funds;
d.business model;
e.customer base;
f.regulated status;
g.BCRA, CNV, UIF or OPNFC filings;
h.AML/KYC policies;
i.sanctions exposure;
j.crypto exposure;
k.cross-border flows;
l.tax registration;
m.local directors, managers or representatives;
n.contracts with customers or partners; and
o.expected transaction volumes.

Treat bank onboarding as a workstream, not an afterthought. A company can be incorporated and tax-registered and still unable to launch if it cannot line up the bank, PSP, payment, custody or settlement relationships the product depends on.

Corporate Setup Should Follow the Regulatory Model

Corporate setup should be built around the regulatory model.

A wallet, a PSPCP, a payment initiator, an acquirer, an OPNFC lender, a PSAV, a crypto platform, a SaaS provider, an API infrastructure company or a cross-border payment business will each call for its own mix of local entity, bank account, registration, contract structure, compliance documentation and operational setup.

The practical sequence should usually be:

a.classify the product and regulatory perimeter;
b.identify whether local registration or partner arrangements are required;
c.choose the corporate structure, usually starting with Article 123 and a local subsidiary for foreign fintech groups;
d.register the foreign shareholder, if applicable;
e.incorporate the local vehicle, typically an SRL or SA depending on the regulatory and operational model;
f.obtain CUIT and ARCA activation;
g.complete bank, PSP or infrastructure onboarding;
h.file any required BCRA, CNV, UIF or OPNFC registrations; and
i.localize contracts, disclosures, policies and compliance documentation before launch.

Corporate setup is not a separate administrative track, then. It is the legal platform the fintech’s regulatory, tax, banking and operational model all rest on.

AML, KYC and Compliance Program

Anti-money laundering, counter-terrorist financing and counter-proliferation financing is a core workstream for any fintech entering Argentina.

It is not a generic compliance checklist. The analysis depends on the company’s regulated status, product type, customer base, flow of funds, asset type, transaction volume, the jurisdictions involved, and whether the company is itself a Sujeto Obligado under the AML framework.

The regime rests mainly on Law No. 25,246 and the regulations of the Unidad de Información Financiera, or UIF. Only the persons, entities and activities listed as regulated subjects fall directly under UIF reporting and compliance. But a fintech that is not a sujeto obligado can still pick up AML/KYC requirements indirectly, through banks, PSPs, custodians, payment processors, acquirers, investors, regulated partners or commercial counterparties.

So for foreign fintechs there are really two questions:

a.Is the company itself a regulated AML subject in Argentina?
b.If not, will its banks, partners or regulated counterparties require an AML/KYC framework as a condition to onboarding or operating locally?

Is the Fintech an AML-Regulated Subject?

A fintech should first work out whether its activity falls within one of the categories of sujetos obligados under Law No. 25,246 and the UIF regulations.

This analysis is particularly relevant for:

a.PSAVs;
b.crypto exchanges;
c.crypto custody platforms;
d.virtual-asset transfer services;
e.payment and collection service providers;
f.non-financial credit providers;
g.financial intermediaries;
h.securities or investment-related platforms;
i.remittance or cross-border payment models;
j.businesses handling high-volume customer funds; and
k.companies operating through regulated partners that require AML allocation.

PSAVs come under a specific UIF regime. Resolution UIF No. 49/2024 sets the minimum requirements they have to implement, on a risk-based approach, for identifying, assessing, monitoring, managing and mitigating money laundering, terrorist financing and proliferation financing risk.

For PSPs, OPNFCs and other models, test the activity against the specific UIF rules that apply. Don’t assume you are either fully unregulated or fully regulated before mapping what the company actually does.

Direct Obligations vs. Indirect Onboarding Requirements

Direct AML obligations apply when the fintech is a sujeto obligado.

Where direct obligations apply, the company may have to register with the UIF, appoint a compliance officer where required, put AML policies in place, run customer due diligence, monitor transactions, file suspicious transaction reports, keep records, carry out risk assessments and meet periodic reporting or information requests.

Indirect AML requirements can land on a company that is not directly regulated at all. It happens most often when the fintech needs:

a.a local bank account;
b.PSP or acquiring relationships;
c.custody or liquidity-provider onboarding;
d.card issuer or processor onboarding;
e.crypto exchange or PSAV partnerships;
f.institutional funding;
g.merchant settlement;
h.payment infrastructure access;
i.payroll or employer integrations;
j.correspondent or cross-border payment relationships; or
k.contractual access to regulated financial infrastructure.

In those cases the regulated counterparty may ask about the fintech’s business model, ownership, beneficial owners, source of funds, compliance program, sanctions exposure, customer profile, transaction volumes, product flows and the jurisdictions involved.

Indirect AML scrutiny can turn into a launch blocker. A product can be perfectly legal yet impossible to launch in practice if banks or regulated partners are not comfortable with the ownership chain, the risk controls or the transaction flow.

Core AML/KYC Elements

Where an AML/KYC program is required, or just commercially necessary, build it around the company’s actual risk profile.

Core elements usually include:

a.customer identification and verification;
b.beneficial ownership identification;
c.risk classification of customers;
d.enhanced due diligence for high-risk customers;
e.sanctions and watchlist screening;
f.politically exposed person screening;
g.transaction monitoring;
h.suspicious transaction detection and escalation;
i.recordkeeping;
j.internal policies and procedures;
k.compliance officer or responsible-person designation, where applicable;
l.employee training;
m.periodic risk assessment;
n.audit or independent review, where applicable; and
o.regulator-facing documentation.

The AML program has to fit the product architecture. A crypto exchange, a wallet, a PSP, an OPNFC lender, an API provider, a marketplace, a cross-border payments business and a stablecoin platform do not share the same risk profile.

It also has to be operationally realistic. A policy that reads well but cannot actually run inside onboarding, transaction monitoring, escalation workflows, vendor systems or reporting will not hold up.

Beneficial Ownership and Corporate Structure

Beneficial ownership comes up again and again for foreign fintechs entering Argentina.

Banks, regulators, PSPs, custodians and commercial counterparties will want to know who ultimately owns and controls the company. That matters most for international groups with holding companies, regional subsidiaries, offshore vehicles, investment funds, shareholder agreements, nominee arrangements or multi-tier structures.

The company should be prepared to provide:

a.corporate chart;
b.shareholder information;
c.ultimate beneficial owner information;
d.constitutional documents;
e.good-standing or existence certificates;
f.board or shareholder approvals;
g.information on controllers and directors;
h.source of funds or source of wealth information where requested;
i.identification documents for relevant individuals;
j.tax residency or compliance information where applicable; and
k.explanations of the commercial rationale for the ownership structure.

This is particularly true for Asian and cross-border groups operating through Hong Kong, Singapore, Cayman, BVI, Delaware, European or other holding structures.

A clean structure takes friction out of bank onboarding, regulatory filings and partner review. One that is technically valid but hard to explain tends to slow everything down.

Enhanced Due Diligence for High-Risk Customers and Jurisdictions

Enhanced due diligence may be required, or simply expected, where the fintech’s customers, shareholders, counterparties, jurisdictions or transaction flows are higher risk.

Potential risk factors include:

a.complex ownership chains;
b.high-risk or non-cooperative jurisdictions;
c.politically exposed persons;
d.crypto exposure;
e.high-volume or high-velocity transactions;
f.cash-intensive activity;
g.cross-border flows;
h.unusual merchant categories;
i.remittance-like use cases;
j.stablecoin settlement;
k.anonymous or pseudonymous asset flows;
l.sanctions-sensitive counterparties;
m.fraud-prone customer segments;
n.rapid customer growth; and
o.inconsistent source-of-funds information.

The key is to define these risk factors before launch and to write down how the company will spot, mitigate and monitor them.

Enhanced due diligence is not something you dust off for an audit. It should live inside onboarding, transaction monitoring, manual review, escalation and partner-risk procedures.

AML Allocation in Partner and White-Label Models

Many foreign fintechs come into Argentina through banks, PSPs, OPNFCs, PSAVs, acquirers, processors, custodians, liquidity providers or other local partners.

There, AML allocation is both a contractual and an operational question. The parties should spell out who onboards customers, who verifies identity, who screens sanctions, who monitors transactions, who files suspicious transaction reports if needed, who handles information requests, who keeps records, who answers the regulator, and who carries the liability when something goes wrong.

The agreement should address:

a.customer ownership;
b.KYC responsibility;
c.reliance on third-party due diligence, where permitted;
d.data-sharing rights;
e.audit rights;
f.suspicious-activity escalation;
g.sanctions controls;
h.transaction-monitoring responsibilities;
i.recordkeeping;
j.regulatory cooperation;
k.subcontracting;
l.incident notification;
m.termination rights for compliance failures; and
n.allocation of losses or penalties.

Don’t assume the local partner soaks up all the AML responsibility. It depends on who the sujeto obligado is, who contracts with the customer, who controls the transaction flow, who holds the data, who provides the regulated service, and what the contract actually says.

Launch Readiness

AML/KYC has to be ready before launch, not bolted on after the company starts onboarding users or moving transactions.

Before going live, a foreign fintech should confirm:

a.whether it is a sujeto obligado in Argentina;
b.whether UIF registration is required;
c.whether a compliance officer or responsible person is required;
d.whether AML policies and manuals are in place;
e.whether customer due diligence workflows are operational;
f.whether sanctions, PEP and adverse-media checks are implemented;
g.whether transaction monitoring is configured;
h.whether suspicious-activity escalation exists;
i.whether recordkeeping is functional;
j.whether customer data can be produced if required;
k.whether partner contracts allocate AML responsibilities;
l.whether banks and regulated counterparties have approved onboarding; and
m.whether the company can demonstrate the rationale for its risk-based approach.

For a foreign fintech entering Argentina, AML is not just a regulatory issue. It decides whether banks will touch you, whether partners will onboard you, and whether you are actually ready to launch.

How Jarsun, Ferreira & Calvo Can Help

Jarsun, Ferreira & Calvo advises fintechs, payment companies, lenders, crypto and virtual-asset businesses, and foreign companies entering Argentina on the regulatory, corporate and compliance issues covered in this guide. Through our Fintech & Financial Regulation practice we help clients map the regulatory perimeter, plan BCRA, CNV and UIF registrations, structure the local entity, and build AML and consumer-protection programs before launch.

For specific engagements, see our services for fintech market entry, PSP registration and compliance, PSAV registration and virtual assets and consumer lending regulation.

For related reading, see our Doing Business in Argentina guide and our analysis of BCRA Comunicación A 8398 and PSP cybersecurity. To discuss a specific project, contact Jarsun, Ferreira & Calvo.

Frequently Asked Questions

Is fintech regulated in Argentina?

Yes, but there is no single fintech regulator or fintech license. Rules apply according to the activity, mainly through the BCRA, the CNV and the UIF, alongside consumer-protection, data-protection and tax authorities.

When does a fintech need to register as a PSP in Argentina?

Registration with the BCRA's payment service provider register is generally required when a company opens or administers payment accounts, holds or transfers customer funds, provides wallet functionality, or acquires or processes merchant payments. The analysis turns on the function, not the label.

Are virtual asset service providers regulated in Argentina?

Yes. The CNV runs a PSAV (VASP) registry under Law No. 27,739, which amended Law No. 25,246. It covers exchange between virtual assets and fiat, exchange between virtual assets, transfer, custody and related financial services.

What is a PNFC or OPNFC in Argentina?

These are non-financial credit providers — companies that lend without taking deposits. Depending on the model and scale, registration with and reporting to the BCRA may apply, and consumer-credit and transparency rules are relevant.

Can a foreign fintech company operate in Argentina?

Yes. Foreign fintechs usually operate through a local subsidiary registered under Article 123 of the General Companies Law, or through a branch under Article 118. The right structure depends on the regulated activity and the operating model.

Which regulators supervise fintech activities in Argentina?

Depending on the activity: the BCRA (payments, foreign exchange and some lending), the CNV (virtual assets and capital markets), and the UIF (AML), alongside consumer-protection authorities, the data-protection authority (AAIP) and the tax authority (ARCA).

Does Argentina impose AML obligations on fintech companies?

Yes, where the activity makes the company a regulated subject — PSAVs are expressly covered. Even when a company is not directly obligated, banks and partners generally require AML readiness before onboarding.

What should a foreign fintech review before launching in Argentina?

The regulatory perimeter across the BCRA, CNV and UIF; any required registrations; corporate setup and tax activation; AML/KYC; data protection; foreign-exchange planning; and consumer-facing terms. The guiding question is always what the product actually does in Argentina.

Start your Argentine fintech launch with a clear regulatory roadmap.

We help fintechs, PSPs, lenders and crypto businesses map the perimeter, plan registrations, structure the local entity and build compliance before launch.

Contact Jarsun, Ferreira & Calvo