Context / Requirement Overview

A major U.S.-based financial services company wants to introduce a new feature to help users with personalised retirement planning. The objective is to support both existing customers (who already have accounts and a history in the system) and new users who may provide only limited information. Instead of building the full advisory logic in-house, the plan is to integrate with a third-party, well-established service that can generate recommendations like contribution strategy, investment allocation, and basic tax-aware guidance.

From the user’s side, the flow should be simple—they start a planning journey, enter or confirm a few details, and get recommendations quickly. These results should also be saved so users can come back and review them later. On the system side, it needs to work with existing internal systems, securely share data with the external provider, and handle cases where data is incomplete, or the third-party service is slow or unavailable. Details like how systems interact, how data is stored, and how failures are handled are not fixed yet and will be defined as part of the architecture.

Problem

The platform shows account and investment data but doesn’t help users with personalized retirement decisions. This makes it harder for users to take action and also limits opportunities to increase engagement and revenue through advisory services.

Constraints

• Must work with existing internal systems (customer, accounts, transactions) without major changes
• Sensitive financial and personal data must be handled securely, especially when shared with external services
• Integration with a third-party advisory system introduces dependency on latency, availability, and API contracts
• Recommendations should be explainable and auditable due to financial regulations
• System should support both existing users (rich data) and new users with limited inputs
• Time-to-market is important, so building complex advisory logic internally is not preferred

Architecture Overview

The solution is designed as a layered system where the platform orchestrates data from internal services and interacts with an external advisory engine to generate retirement recommendations. A dedicated orchestration layer handles the end-to-end flow—collecting user data, preparing the request, calling the third-party service, and returning the response to the user interface.

Internal systems such as customer profiles and account services are accessed through well-defined APIs, keeping them decoupled from the new capability. An integration layer abstracts the communication with the external advisory service, allowing flexibility to handle failures, retries, or future provider changes. Recommendations are stored for later access, enabling users to revisit past plans and ensuring auditability.

Image that will have UI (Web/Mobile) API Gateway (optional but good) Orchestration Service (important) Internal Services: Customer Service Account/Portfolio Service Integration Layer / Adapter External Advisory Service Recommendation Store (DB)

Decisions

1. Use External Advisory Service (Build vs Buy)

Chose to integrate with a third-party advisory engine instead of building recommendation logic internally. This helps reduce time-to-market and leverages domain expertise, while keeping internal systems simpler.

2. Introduce an Orchestration Layer

Added a dedicated service to manage the end-to-end flow instead of embedding logic across multiple services. This keeps the system easier to manage and centralizes the planning workflow.

3. Abstract Third-Party Integration

Used an adapter/integration layer between the platform and the external service. This avoids tight coupling and makes it easier to handle API changes or switch providers in the future.

4. Persist Recommendations

Decided to store both inputs and generated recommendations. This allows users to revisit past plans and supports audit and compliance requirements.

5. Support Partial Data Inputs

Designed the system to work even when full user data is not available. This enables the onboarding of new users while still providing meaningful recommendations.

6. Hybrid Interaction Model

Used a mostly synchronous flow for generating recommendations, with flexibility to handle delays or fallback scenarios. This balances user experience with external dependency constraints.

Trade-offs

-

Outcome

-

Back to List