Building Fego.ai's Open Banking Product Suite from a One-Line Brief on India's Account Aggregator Framework

Market research and ecosystem mapping: establishing what existed, what transferred, and what the Indian market actually needed

The first task was to establish what the product needed to be. The team studied Meniga, Tink, and Strands in detail, mapping where their architectures assumed regulatory environments that didn't apply to AA.

Gaps were documented:

1. consent management flows, financial institution data schemas, transaction categorisation trained on Western spending patterns.
2. Each gap was either a build scope item or a sourcing requirement for a third-party tool.
3. For niche functionality, Finbit, 3LOQ, and OneMoney were benchmarked directly and integrated where they performed, with intelligent feedback loops built using crowdsourced data to improve classification accuracy on Indian financial transactions over time.

The output was a validated product scope, a clear architecture direction, and a set of integration partners whose performance had been tested rather than assumed.

This phase produced

• Global open banking benchmark study (Meniga, Tink, Strands)
• AA framework gap analysis
• Niche tool evaluation and benchmarking (Finbit, 3LOQ, OneMoney)
• Integration feasibility report
• Crowdsourced feedback loop design
• Validated product scope

High-fidelity prototypes and investor validation: features locked by market feedback

With scope established, the next constraint was validating features before engineering resources were committed. The team built clickable high-fidelity mockups covering both product surfaces: the Customer Insights PFM interface for end users and the Partner Insights analytics dashboard for financial institution users. These were pitched to prospective clients and investors.

Features that failed to resonate were discarded during discovery. Features with consistent demand were locked into the production backlog with validated intent behind them. The two surfaces, customer PFM and partner analytics, were architected to share the same underlying consented data layer while presenting entirely different interfaces and interaction models, a design decision made at this stage that determined the production architecture that followed.

This phase produced

• Customer Insights (PFM) high-fidelity mockups
• Partner Insights dashboard mockups
• Investor and client pitch materials
• Feature validation and discard log
• Validated production feature backlog
• Dual-surface information architecture

Cloud-native platform build: one codebase, four integration models, AES-256 encryption by design

The platform was built around a single architectural constraint: every financial institution integrating it would have a different stack and different integration preferences. The four delivery modes, federated modules, micro frontend widgets, REST APIs, and embeddable standalone apps, were not four separate builds.

They were four exposure surfaces of the same underlying platform, designed so a bank could embed a widget, a fintech could call the API, and an institution with no existing app could deploy the standalone experience. Security was built into the schemas, not layered on afterward: data anonymisation was a schema-level decision and AES-256 encryption covered all data at rest and in transit across the cloud-native, microservices architecture.

This phase produced

• Cloud-native microservices platform
• REST API layer
• Federated module delivery
• Micro frontend widget SDK
• Embeddable standalone apps
• Schema-level data anonymisation
• AES-256 encryption (at rest and in transit)
• Transaction categorisation with feedback loop integration