Financial services businesses handle large amounts of sensitive client information every day. Employees may need to review financial documents, identify important facts, organize client information, prepare recommendations, and produce professional reports that follow strict internal standards.<\/span><\/p>\n Traditionally, much of this work is performed manually. Employees read documents, copy relevant information into internal records, refer to approved wording and templates, prepare reports, and then review everything before sending it to the client. Although this process can be effective, it can also be time-consuming and vulnerable to inconsistencies.<\/span><\/p>\n This case study explores how <\/span>CnEL India<\/b> could approach the development of a secure, multi-user AI-powered financial report writing application for a UK-regulated financial services firm.<\/span><\/p>\n The goal is not to create a simple chatbot. Instead, the proposed solution is a secure business application that can process authorized client documents, organize evidence, generate reports using approved business rules, maintain traceability, and require human approval before any report becomes final.<\/span><\/p>\n Because the application would process confidential personal and financial information, security, privacy, governance, auditability, and accuracy would be fundamental parts of the architecture.<\/span><\/p>\n The client requires a shared application that can be used by multiple authorized employees.<\/span><\/p>\n An employee should be able to upload relevant client documents, after which the system can identify and organize useful information into a structured case record.<\/span><\/p>\n The application can then use this structured information, approved templates, internal guidance, and authorized wording to prepare a draft financial report.<\/span><\/p>\n The employee can review the draft, verify the supporting information, make necessary changes, and approve the final version.<\/span><\/p>\n The overall workflow can be represented as:<\/span><\/p>\n Document Upload \u2192 Information Extraction \u2192 Evidence Organization \u2192 Case Record \u2192 Report Generation \u2192 Source Verification \u2192 Human Review \u2192 Approval \u2192 Final Report<\/b><\/p>\n This separation is extremely important.<\/span><\/p>\n The system should not simply send an entire document to an AI model and ask it to “write a report.” That approach can make it difficult to determine where individual statements came from and can increase the risk of unsupported information appearing in the final document.<\/span><\/p>\n Instead, CnEL India’s approach would separate the process into controlled stages.<\/span><\/p>\n The application would be designed for multiple employees rather than a single user.<\/span><\/p>\n Different employees may have different responsibilities, so access should be controlled according to their roles.<\/span><\/p>\n For example, the system could support roles such as:<\/span><\/p>\n A normal employee might be allowed to upload documents and prepare reports but may not be allowed to modify approved templates or internal rules.<\/span><\/p>\n An administrator, on the other hand, could manage templates, approved wording, instructions, and other configurable business content.<\/span><\/p>\n This role-based structure helps ensure that sensitive configuration cannot be changed accidentally or by unauthorized users.<\/span><\/p>\n Financial reports can depend on information contained in many different documents.<\/span><\/p>\n These may include:<\/span><\/p>\n The application should support common document formats such as Word and PDF.<\/span><\/p>\n Once documents are uploaded, the system would process them and extract relevant information.<\/span><\/p>\n However, extraction should not immediately become final client information.<\/span><\/p>\n The system should preserve the relationship between the extracted information and the original source document.<\/span><\/p>\n For example, if the client’s annual income is identified from a particular document, the system should retain information about where that value originated.<\/span><\/p>\n This creates a foundation for later verification and auditability.<\/span><\/p>\n One of the most valuable parts of the proposed application would be the structured case record.<\/span><\/p>\n Instead of keeping client information as unorganized text, the application can organize important information into defined fields.<\/span><\/p>\n For example:<\/span><\/p>\n Client Details<\/b><\/p>\n Financial Information<\/b><\/p>\n Objectives<\/b><\/p>\n Supporting Evidence<\/b><\/p>\n The exact fields would depend on the firm’s internal workflow.<\/span><\/p>\n This structured approach allows the report-writing process to operate on organized information instead of relying entirely on free-form interpretation.<\/span><\/p>\n A key requirement in this project is separating <\/span>document extraction, evidence organization, and report generation<\/b>.<\/span><\/p>\n These should be treated as different stages.<\/span><\/p>\n The application identifies information contained in uploaded documents.<\/span><\/p>\n The extracted information is structured and connected to its source.<\/span><\/p>\n The system identifies missing, ambiguous, or conflicting information.<\/span><\/p>\n Only validated and relevant information is used to prepare the report.<\/span><\/p>\n This architecture creates a much stronger foundation for accuracy.<\/span><\/p>\n For example, if two documents contain different values for the same financial figure, the application should not silently select one.<\/span><\/p>\n Instead, it should identify the conflict and request human review.<\/span><\/p>\n The report-writing component would generate content based on approved information rather than freely inventing content.<\/span><\/p>\n The system would be provided with:<\/span><\/p>\n The generated report would then follow the firm’s predefined structure.<\/span><\/p>\n This helps ensure that different employees receive consistent report formats and writing styles.<\/span><\/p>\n The AI component would essentially operate within controlled boundaries rather than being allowed to generate unrestricted financial statements.<\/span><\/p>\n The client specifically requires a distinction between fixed approved wording and AI-generated content.<\/span><\/p>\n This is important in a regulated environment.<\/span><\/p>\n Some sections of a report may need to use exact language approved by the organization.<\/span><\/p>\n Other sections may require dynamic wording based on individual client information.<\/span><\/p>\n The application can therefore classify content into two categories.<\/span><\/p>\n This includes approved language that should remain unchanged unless an authorized administrator updates it.<\/span><\/p>\n This includes information generated from the client’s case data and supporting evidence.<\/span><\/p>\n Keeping these categories separate makes the report easier to control and review.<\/span><\/p>\n It also reduces the possibility of the AI unintentionally changing important approved language.<\/span><\/p>\n The client should not have to modify application code every time an approved template or business instruction changes.<\/span><\/p>\n Therefore, templates, approved wording, and internal guidance should be managed through an administrative interface.<\/span><\/p>\n Authorized administrators could:<\/span><\/p>\n Every significant change should be versioned.<\/span><\/p>\n For example, if a report was generated using Template Version 3, the system should retain that information.<\/span><\/p>\n This becomes valuable during later reviews because the firm can identify exactly which template and instructions were used when the report was created.<\/span><\/p>\n Traceability is one of the most important requirements of the project.<\/span><\/p>\n Every important generated statement should ideally be connected to supporting evidence.<\/span><\/p>\n For example, if a report says that a client has a specific level of annual income, the reviewer should be able to identify the document and source information supporting that statement.<\/span><\/p>\n This could be represented within the internal application as evidence references.<\/span><\/p>\n The final client-facing report does not necessarily need to expose every internal reference, but the business system should retain the information for review and audit purposes.<\/span><\/p>\n This creates a clear chain:<\/span><\/p>\n Source Document \u2192 Extracted Fact \u2192 Structured Case Record \u2192 Generated Statement \u2192 Final Report<\/b><\/p>\n Such traceability makes human review more effective and supports future investigation if questions arise.<\/span><\/p>\n AI systems can sometimes generate information that is not supported by the source material.<\/span><\/p>\n For a financial services organization, this is a serious risk.<\/span><\/p>\n The application should therefore be designed around a “known information only” principle.<\/span><\/p>\n If the source documents do not provide sufficient information, the system should not attempt to guess.<\/span><\/p>\n Instead, it could flag the issue as:<\/span><\/p>\nUnderstanding the Business Requirement<\/b><\/h1>\n
Multi-User Business Application<\/b><\/h1>\n
\n
Secure Document Processing<\/b><\/h1>\n
\n
Structured Case Records<\/b><\/h1>\n
\n
\n
\n
\n
Separating Extraction from Report Writing<\/b><\/h1>\n
Stage 1: Extraction<\/b><\/h3>\n
Stage 2: Evidence Organization<\/b><\/h3>\n
Stage 3: Validation<\/b><\/h3>\n
Stage 4: Report Generation<\/b><\/h3>\n
Grounded Report Generation<\/b><\/h1>\n
\n
Approved Wording and AI-Generated Content<\/b><\/h1>\n
Fixed Content<\/b><\/h3>\n
Dynamic Content<\/b><\/h3>\n
Template and Instruction Management<\/b><\/h1>\n
\n
Source Traceability<\/b><\/h1>\n
Controlling Hallucinations and Unsupported Information<\/b><\/h1>\n
\n