How to obtain ITFB authorization from SUDEBAN

What an ITFB is and why it matters

SUDEBAN Resolution No. 001.21, the Rules governing financial technology services, created the framework for technology companies to provide financial services in the Venezuelan banking sector under supervision. The central figure is the banking-sector financial technology institution, known as an ITFB: a company that, with prior authorization from SUDEBAN, offers services such as wallets, payments, collections or financing platforms built on technology.

The regulation has two practical effects. First, it establishes that these services cannot be provided freely: they require authorization and fall under the Superintendency's supervision. Second, it organizes the relationship between banks and Fintech providers, so that a partnership between them has clear rules on responsibility, data and service continuity.

For an entrepreneur or a financial group, ITFB authorization is the difference between running your own product and always depending on someone else's license. For a bank, understanding the figure helps evaluate partners: an authorized ITFB has already been examined on corporate governance, risk and technology.

Who needs authorization

The general rule is simple: if your company will provide a technology-based financial service to the public within the scope of the banking sector, you should check whether the activity falls under the services regulated by Resolution 001.21. The most common cases are:

• Electronic wallets that hold user balances or move them between accounts.
• Digital payment, collection and acquiring services for merchants, including QR code payments and acceptance on phones.
• Platforms that connect users with financing products or manage payments on behalf of third parties.
• Companies that integrate with banks to offer, under their own brand, services that touch customer funds or data.

Not every technology provider needs to be an ITFB. A company that only licenses software to a bank, without dealing with the public or handling funds, is usually treated as the bank's technology provider, and the bank remains responsible to SUDEBAN. That is Alodiga's case: it is a technology provider, it does not take deposits from the public and does not provide financial services on its own account. The line between the two models depends on the details of the service, so it is worth analyzing it with your legal counsel before designing the product.

The regulatory framework around authorization

Resolution 001.21 does not apply in isolation. A solid application shows that the model complies with the body of rules that already governs the banking sector. The most relevant for an ITFB are:

You can see the full list of regulations that apply to each module in Security and compliance and a country view in Core banking in Venezuela.

The process, step by step

Each application is different, but authorization processes before a banking supervisor follow a similar logic. This is the sequence worth planning for:

1. Assessment and business model definition

Before drafting documents, define precisely what service you will provide, to whom, through which channels, with which funds and with which bank partners. This definition determines which regulations apply and how much weight each chapter of the application carries. A common mistake is to describe the product in commercial rather than operational terms: the Superintendency needs to understand how money and data flow.

2. Preparing the application file

This is the longest phase. It includes corporate documents, information on shareholders and directors, the business plan and the policy and procedure manuals. In parallel, the technical team documents the architecture, security controls and continuity plan. Working on both fronts at once prevents the technology section from being improvised at the end.

3. Submission and evaluation

The application is submitted to SUDEBAN through the channels and formats it specifies. During the evaluation, the supervisor reviews the suitability of shareholders and managers, the viability of the business, risk management and technological soundness. It is normal for the evaluation to include meetings and presentations of the model.

4. Observations and adjustments

It is usual to receive observations: clarifications on the flow of funds, adjustments to manuals or additional information about providers. Responding quickly and with concrete evidence (diagrams, contracts, test results) shortens this stage. Decide in advance who answers each type of observation.

5. Authorization and start of operations

Once authorized, the institution prepares to start operations under the conditions set by the Superintendency, which may include prior verifications. From then on it is subject to ongoing supervision: reports, inspections and the obligation to maintain the controls described in the application.

Note: This guide does not state timelines or capital amounts because they depend on the Superintendency and on each case. Ask SUDEBAN or your legal counsel for those figures; do not take them from informal sources.

Typical documents in the application

The definitive list is set by SUDEBAN. The one below is indicative and reflects what is usually requested in banking-sector authorization processes:

Corporate and governance

• Articles of incorporation and bylaws, with a corporate purpose aligned with the service.
• Shareholding structure up to the ultimate beneficial owner and the source of the funds contributed.
• Identification, track record and fit-and-proper statements of directors and managers.
• Organizational structure with independent risk, compliance and audit functions.

Business

• Business plan describing the service, target market and reasoned projections.
• Description of the flow of funds and, where applicable, of partnerships with banks.
• Standard contracts with users, merchants and partners, with clear fees and conditions.

Risk and compliance

• LC/FT/FPADM prevention manual in line with Resolution 010.25, including a know-your-customer policy.
• Risk management methodology, including operational and technology risk.
• Complaint handling and user protection procedures.

Technology

• Platform architecture, where data is hosted and how partners are integrated.
• Information security, access management and encryption policies.
• Business continuity and disaster recovery plan, with tests.
• Contracts with technology providers covering confidentiality, audit and exit.

The role of technology in the application

In an ITFB, technology is not an appendix: it is the service. That is why the technical evaluation weighs as much as the financial one. The supervisor wants to see that the institution knows where its data is, who accesses it, how fraud is detected and what happens if a system fails.

There are four questions a good platform helps answer with evidence:

1. Traceability. Can you reconstruct every operation with its user, channel, date and result? An immutable ledger and audit logs make this possible.
2. Customer due diligence. How do you verify identities and monitor transactions? See AloCompliance for KYC, KYB and transaction monitoring.
3. Fraud prevention. Which rules and models detect anomalous behavior, and who reviews the alerts? See AntiFraude.
4. Continuity. What is the plan if a component or a provider goes down? Cloud architecture and recovery plans must be documented and tested.

If the project is a wallet or a payment acceptance service, the Digital Wallet and Punto Digital pages detail the regulations that apply to each product. As a technology provider, Alodiga can give your team the platform's technical documentation for the application file; the application and the responsibility before SUDEBAN remain with the institution.

Common mistakes

• Submitting a commercial business plan without an operational, verifiable flow of funds.
• Treating the LC/FT/FPADM manual as a generic document copied from another institution.
• Choosing the technology platform after submitting the application and having to redo the technical section.
• Not defining how the relationship with a provider will end (orderly exit and return of data).
• Underestimating the time needed to answer observations because no one owns each topic.

Checklist before submitting

• The service, the users and the flow of money are described on one page anyone can understand.
• Applicable regulations are identified and each has an internal owner.
• Risk and LC/FT/FPADM prevention manuals are adapted to the real model.
• Architecture, security controls and the continuity plan are documented and tested.
• Contracts with partners and providers cover confidentiality, audit and exit.
• Your legal counsel has reviewed the complete file against the current version of Resolution 001.21.