Multi-Company Banking Authorization

Bringing multiple authorization flows into one place. Multi-Company Authorization was designed to centralize pending banking operations from different companies into a single dashboard. Instead of navigating through separate authorization modules, users could review their companies, explore pending financial products, select individual operations and complete multiple authorizations from one experience. This was directly aligned with the functional goal of the product: centralizing authorizations from different companies and enabling multiple operations to be authorized simultaneously.

Frontend ownership. I was responsible for the frontend development of the Multi-Company authorization experience using Angular and TypeScript. My work covered the different financial products integrated into the platform, their operation-specific flows, shared interaction patterns, authorization states and integration with the surrounding banking portal.

Progressive authorization. The main navigation followed three levels. Company — The user starts by viewing the companies with pending operations. Each company could show information such as company identification, pending products, number of operations, total amount and access to detail. Product — When opening a company, its financial products with pending operations were shown. The user could modify the product selection and access the detail of each one. Operation — Finally, the user could individually select the operations they wanted to authorize. The detail varied depending on the financial product.

More than checkboxes. Selection was one of the core pieces of frontend logic. The interface needed to synchronize selections between companies, products and operations while continuously reflecting partial selections, disabled states and selection limits. Selecting a company could automatically select its products and operations; selecting a product could select all of its operations; reaching 100 operations blocked additional selections; checkboxes started disabled; and the interface contemplated total, partial and no selection.

A shared experience across different banking products. I developed the frontend implementations for the products integrated into the Multi-Company experience. Although they shared the same authorization model, each product could introduce different information, rules and operation-specific behavior.

Consistency without forcing identical workflows. The different products shared components and interaction patterns, but their operation details were not identical. The frontend architecture had to preserve a consistent authorization experience while still supporting specialized components and business rules for each product. MultiempresaModule concentrated the routes and components associated with these experiences.

Consistency didn't mean identical behavior. Some products introduced significantly more complex rules, including currencies, expiration periods, operating schedules and different exchange-rate modalities. Payment Orders (OPE) is a clear example. The frontend had to communicate these restrictions clearly while preserving the same overall interaction model.

Built for production.

The result was a unified frontend capable of supporting multiple companies, financial products and operation types through a consistent authorization experience. From company-level navigation to product-specific operation details, security validation and authorization receipts, the microfrontend brought complex banking workflows into a single interface. The result matched the original purpose of centralizing the authorizations of multiple companies into a single experience.

Reusability has limits — Shared components are valuable, but different business domains sometimes require specialized implementations. State is part of the product — In complex workflows, state management directly determines whether the interface correctly represents the underlying business process. Enterprise frontend is integration — Building the interface is only part of the challenge. The application also has to coexist with existing design systems, security flows, backend services and deployment infrastructure. Edge cases matter — Success, partial success, disabled states, operation limits and errors are part of the main experience—not secondary details.