Regulation, safety, and innovation: how to advance in financial products without increasing risk.

For a long time, the financial market treated innovation and control as opposing forces. On one side, product and technology sought to reduce time to market. On the other, security, risks, and compliance entered the process to review decisions and prevent speed from creating vulnerabilities. In my view, this opposition is less about regulation and more about how companies organize development.

The numbers show why we need to overcome this model. According to the Febraban Banking Technology Survey 2026, 83% of banking transactions already happen through digital channels, with 78% via mobile. The same survey indicates that cybersecurity is a priority for 100% of participating institutions. Open Finance, in turn, already has over 126 million users, expanding the consented circulation of data and the possibilities of creating personalized services.

As financial products become more digital and connected, the surface that needs to be protected increases. Pix, Open Finance, anti-fraud models, and investment journeys depend on continuous integrations, automated decisions, and the handling of sensitive information. At the same time, rules such as the CVM Resolution 30, related to suitability, require verifiable procedures and controls to ensure the suitability of products and operations to the profile of each client.

In this environment, leaving compliance until the end of development is an inefficient strategy. When risks and controls are evaluated only before launch, architectural decisions have already been made, integrations are ready, and changes become more costly. The result is often a conflict between deadlines and security — when both should have guided the product from the start.

I advocate that regulation, security, and innovation be treated as dimensions of the same design. Access controls, consents, audit trails, segregation of duties, and data protection can be incorporated into the architecture and automated throughout the journey. When this happens, compliance ceases to be an approval step and becomes a permanent capability of the product.

This requires bringing together product professionals, engineering, security, risks, and compliance. Not to increase the number of meetings or create new barriers, but to transform regulatory requirements into testable technical decisions. That’s how we can innovate quickly without transferring risks to the operation or the customer.

Are speed of innovation and control really opposites?

I don’t believe that speed and control are incompatible objectives. The conflict arises when controls are added only at the end of development, after key decisions about architecture, data, and experience have already been made.

In this model, security and compliance receive a practically finished product and need to identify risks in a short time. Any adjustment starts to be interpreted as a delay, even when it corrects a decision that could have been discussed at the beginning.

When control requirements enter planning, teams can turn them into clear development criteria. Access rules, operational limits, evidence, and validations become part of the product. This reduces rework and makes the launch more predictable.

Sustainable speed does not mean eliminating controls. It means automating them and executing them throughout the entire journey.

What changes when compliance enters product design?

Compliance by design means considering regulatory requirements from conception. Before developing a feature, the team identifies what data will be used, who can access it, what decisions need to be recorded, and how potential exceptions will be handled.

In an investment product, for example, suitability should not just be a validation performed before onboarding. Suitability to the client’s profile needs to guide recommendations, alerts, blocks, and records produced by the journey itself.

The same applies to consents in Open Finance, anti-fraud rules, and anti-money laundering. When these requirements are part of the design, the product is already born prepared to:

• collect only necessary data;
• validate permissions and consents;
• apply business rules consistently;
• register decisions and exceptions;
• generate verifiable evidence;
• adapt to regulatory changes.

This does not eliminate compliance participation. On the contrary, it transforms the area into a partner in defining the product, rather than keeping it merely as the final approval instance.

Can the audit trail be a byproduct of the architecture?

Yes. In a well-designed architecture, the audit trail is generated automatically while the product operates. Each relevant action leaves a structured record, identifying the user or system, date, time, context, and outcome.

If a client alters their profile, grants consent, or performs an operation, the platform should record not only the final outcome but also the rules applied and the decisions made throughout the flow.

For these pieces of evidence to be reliable, I consider several precautions essential:

• records protected against unauthorized changes;
• synchronized timestamps between systems;
• unique identification of each operation;
• event correlation across different services;
• clear retention policies;
• restricted access to information;
• monitoring of administrative actions.

When the trail is constructed this way, reports and evidence no longer depend on manual collection from different systems. Audit and compliance consult a consistent source, reducing effort and increasing investigatory capacity.

Security from the architecture: what does that mean in practice?

Security from the architecture means making protection decisions before implementation. It’s not enough to test vulnerabilities close to launch or install tools after the product is ready.

In practice, this principle involves defining from the outset:

• authentication and authorization;
• segregation of duties;
• data encryption;
• protection and rotation of credentials;
• management of APIs and integrations;
• transactional limits and validations;
• monitoring of abnormal behaviors;
• incident response;
• service continuity and recovery.

It is also important to adopt the principle of least privilege: each person, application, or service should only access the resources necessary for their function.

Security must accompany the entire product lifecycle. Code analyses, automated testing, dependency management, and incident simulations should be part of the ongoing development process.

In my view, a secure architecture is not one that promises to prevent any failure. It is one capable of reducing the likelihood of incidents, limiting their impacts, and producing sufficient information for a rapid response.

Why do product, technology, and compliance still decide separately?

This separation is often a consequence of the organizational structure itself. Product is pressured for growth and experience; technology, for stability and deliveries; security, for protecting the environment; and compliance, for adherence to regulations.

When each area works with its own indicators, risks are discussed too late. Product defines the journey, technology implements it, and compliance reviews it at the end. This sequence creates rework and reinforces the perception that control reduces speed.

One alternative is to form multidisciplinary teams from the product discovery phase. Regulatory requirements can be translated into stories, acceptance criteria, and automated tests. Security and compliance participate in the most sensitive decisions while the team maintains autonomy to execute the rest.

The case of the credit cooperative served by Objective demonstrates this balance. The institution needed to replace an automation platform that no longer provided adequate governance, security, and scalability for about 50 critical processes.

The evolution began with a diagnosis that evaluated technology options based on criteria of scale, security, governance, and regulatory adherence. The solution incorporated permission management, integration with existing automations, and training for the internal team.

In four months, between four and six processes were already in production, including account opening, product management, and lines of credit. The result helps show that governance embedded in design does not need to delay innovation. It can create a foundation for accelerating new deliveries with more autonomy and predictability.

Control can also be an innovation capability

The financial sector does not need to choose between launching products quickly and operating securely. The question is when and how controls enter the process.

When compliance, security, and traceability are incorporated into architecture, new features can reuse already validated capabilities. A consent mechanism, an access policy, or a well-structured audit trail do not serve just for one delivery: they become components of evolution for different products.

That’s how I see the relationship between innovation and risk. Control should not be a barrier added at the end. It should be part of the infrastructure that allows continuous innovation.

Innovate with speed, security, and governance

Does your company need to develop or modernize financial products without increasing operational risks? Contact the experts at Objective and discover how to integrate product, technology, security, and compliance from the beginning of the journey.

Frequently asked questions on the topic