← Thinking
2026-03-28Case Study

Non-Intrusive Securities Mid-Office Transformation: Three AI Scenarios

Background

In early 2025, a domestic To B securities fintech company approached us. They'd been in the securities services business for over a decade with a mature data mid-office system containing stock data, product data, personnel data, and more.

The problem: the system was too old.

The code was written over a decade ago, with developers cycling through multiple generations. The code style was inconsistent, comments were missing, and the logic was chaotic. In their own words: "This is a mountain of legacy code, but we still have to build on top of it."

They wanted to add AI capabilities but had two hard constraints:

  1. Cannot modify the original system. The system has been running for over a decade, and stability is paramount. Any changes require rigorous testing and approval, with long cycles and high costs.
  2. Cannot take the system offline for upgrades. The system runs 24/7, serving dozens of securities firms. Every day of downtime is a day of losses.

So we proposed a solution: non-intrusive transformation.

What is Non-Intrusive Transformation

Simply put, it means layering AI capabilities on top of the existing system, rather than replacing it.

The specific approach:

  1. Add a floating ball. Add a small circle in the bottom-right corner of the existing system. Clicking it opens a chat dialog. Users can interact with the system using natural language.
  2. Deploy AI services independently. The AI service runs on separate servers, communicating with the existing system via API. The existing system doesn't need any changes.
  3. Roll out gradually. Launch one scenario first, stabilize it, then launch the second, and finally the third. Each scenario is independent and doesn't affect the others.

Benefits of this approach:

  • Zero changes to the existing system, risk可控
  • Independent AI service deployment, performance可控
  • Independent scenario rollouts, timeline可控

Three Scenarios

We chose three scenarios to切入, each with different logic.

Scenario 1: Smart Authorization

Problem: The system has many roles, each with different permissions. The roles are numerous and messy, making management very cumbersome.

The original workflow: administrators manually configure permissions for each role. If 5 roles need changes, the administrator must enter 5 separate pages and modify each one. After making changes, they must check each one individually, fearing they might have missed or incorrectly modified one.

Pain points:

  • Too many roles, tedious operations
  • Easy to miss changes or make errors
  • Inconvenient to view permissions, requiring page navigation

Our solution:

Use natural language to manage permissions. Administrators just need to say one sentence, like "give interns view access to Product A," and the system automatically:

  1. Intent recognition: Determines the user wants to change permissions
  2. Parameter extraction: Extracts the role (interns), permission (view), and object (Product A)
  3. Secondary confirmation: Shows a confirmation dialog: "Will add view access for Product A to the intern role. Confirm?"
  4. Execute operation: Calls the permission management API to complete the permission change
  5. Result confirmation: Displays the modified permission list for final confirmation

Why secondary confirmation?

Because permission management is a high-risk operation. Errors can lead to data leaks or business interruptions. So we added confirmation at two critical points:

  • Pre-execution confirmation: Verify intent understanding is correct
  • Post-execution confirmation: Verify the operation result meets expectations

Technical details:

  • Intent recognition: Uses prompt engineering to identify user intent. Since their deployed model is DeepSeek V3 (though they claim it's self-developed), its tool-calling capabilities are slightly weaker, so we optimized prompts specifically for this model's characteristics.
  • Tool encapsulation: Since the original code was too messy, we didn't modify the original framework. Instead, we created an independent package that encapsulates permission management APIs as tools. This doesn't affect the original code and makes future maintenance easier.
  • Floating ball interaction: Created a floating ball + chat dialog UI, allowing users to complete operations without leaving their current page.

Scenario 2: Smart Integration

Problem: The system has many documents scattered across various locations. Finding information requires searching through many documents.

For example, a user wants to learn about "Financial Product A." The basic info is in one document, risk rating in another, historical returns in a third, and sales pitch in a fourth. The user must open four documents and search through each one — very inefficient.

Pain points:

  • Documents scattered, difficult to find
  • Information fragmented, requires manual integration
  • Time-consuming, easy to miss information

Our solution:

Use AI for document integration. Users just need to ask "Financial Product A info," and the system automatically:

  1. Document retrieval: Uses RAG (Retrieval-Augmented Generation) technology to retrieve documents related to "Financial Product A" from all documents
  2. Information extraction: Extracts key information from each document
  3. Summary display: Integrates all information and displays it to the user

Display approach:

We created a two-layer display:

  • Layer 1: Document list. Lists all documents containing "Financial Product A" information. Users can click to view the original text.
  • Layer 2: Information summary. Extracts all key information into a structured table for quick browsing.

Technical details:

  • RAG: Uses vector databases to store document embeddings and semantic retrieval to find relevant documents.
  • Information extraction: Uses LLM to extract key information from documents, such as product name, risk rating, return range, target audience, etc.
  • Tool encapsulation: Similarly encapsulated as independent tools, accessible via the floating ball.

Scenario 3: Smart Content Generation

Problem: Sales staff need to recommend products to clients, but understanding products is a tedious task.

Sales staff need to know:

  • What are the product's features?
  • What kind of clients is this product suitable for?
  • How to express the product's highlights in plain language?

This information is scattered across product documents, sales manuals, and training materials. Sales staff must search through many materials to prepare a recommendation pitch.

Pain points:

  • Time-consuming to understand products
  • Inconsistent quality of recommendation pitches
  • Slow onboarding for new products

Our solution:

Use AI to generate recommendation pitches. Sales staff just need to ask "help me write a recommendation pitch for Financial Product A," and the system automatically:

  1. Product analysis: Analyzes the product's features, highlights, risk level, and target audience
  2. Pitch generation: Generates an easy-to-understand recommendation pitch based on the analysis
  3. Personalized adjustment: Adjusts the pitch's focus based on the salesperson's client profile

Examples:

  • If a product has 5% annualized returns but has maintained 5% for 10 consecutive years, the pitch emphasizes "stability": "While this product doesn't have the highest returns, its strength is consistency. Over the past 10 years, it has maintained 5% returns every year, making it ideal for stability-focused investors."
  • If a product comes from a well-known company, the pitch emphasizes "brand": "This product comes from XX Company, one of the largest XX institutions in the country, with a trustworthy brand."
  • If a product is newly launched, the pitch emphasizes "novelty": "This is a new product with no similar alternatives on the market, perfect for investors who enjoy trying new things."

Technical details:

  • Product analysis: Uses LLM to analyze product documents and extract features, highlights, and target audience.
  • Pitch generation: Uses LLM to generate pitches based on analysis, with prompts controlling the style and focus.
  • Tool encapsulation: Similarly encapsulated as independent tools, accessible via the floating ball.

Why We Cut It This Way

These three scenarios look different on the surface, but there's logic behind our selection:

  1. By pain intensity: Smart Authorization > Smart Integration > Smart Content Generation. Permission management is used daily and errors have severe consequences; document integration is high-frequency with clear efficiency gains; content generation is a nice-to-have that improves quality.
  2. By implementation difficulty: Smart Authorization < Smart Integration < Smart Content Generation. Permission management APIs are readily available, requiring only intent recognition and tool calls; document integration requires RAG, adding complexity; content generation requires understanding products and clients, making it most complex.
  3. By risk level: Smart Authorization > Smart Integration > Smart Content Generation. Permission management is high-risk, requiring multiple confirmations; document integration is medium-risk, as incorrect information could mislead decisions; content generation is low-risk, as a poor pitch at worst loses one client.

So our launch order was: Smart Authorization → Smart Integration → Smart Content Generation.

We launched the most painful, most difficult, and highest-risk scenario first because once done well, it significantly boosts client trust. Plus, the APIs for this scenario were readily available, keeping technical risk可控.

Tool Assembly Factory

While building these three scenarios, we discovered a pattern: each scenario required tool encapsulation, but the encapsulation approach was similar.

So we built a "Tool Assembly Factory":

  1. Unified tool interface: All tools follow the same interface specification, including input parameters, output formats, error handling, etc.
  2. Automated tool generation: Just provide the API address and parameters to automatically generate tool code.
  3. Unified tool management: All tools are registered in one place for easy discovery, reuse, and updates.

Benefits:

  • Faster new scenario launches, no need to reinvent the wheel
  • More stable tool quality thanks to unified standards
  • Easier future maintenance with all tools in one place

Moreover, this Tool Assembly Factory is itself non-intrusive. When clients want to add new AI scenarios in the future, they just need to add new tools to the factory without modifying the existing system.

Results

After launching all three scenarios:

  • Smart Authorization: Permission management efficiency improved by 80%, operation error rate reduced by 95%.
  • Smart Integration: Document search time reduced from an average of 30 minutes to 2 minutes.
  • Smart Content Generation: Pitch generation time reduced from 1 hour to 5 minutes, pitch quality score improved by 40%.

More importantly, zero changes to the existing system, zero downtime.

Final Thoughts

This project taught us several things:

  1. Non-intrusive transformation is viable. For legacy systems, the cost and risk of rip-and-replace are too high. Layering AI capabilities is a more pragmatic choice.
  2. Scenario selection matters. Not all scenarios are suitable for AI. We need to choose scenarios with strong pain points, sufficient data, and enough room for error.
  3. Toolization is key. Encapsulating AI capabilities as tools enables reuse, scalability, and maintainability.

If you have a legacy system you'd like to add AI capabilities to, feel free to reach out.