My Internship Journey: Building AI in Banking

I interned with the GFM — Data Team. Broadly, the team supports data-driven decision-making within financial markets by building dashboards, performing analysis, and developing automation solutions that reduce manual work. These improvements affect operational risk, auditability, and the speed at which other teams can act on information.

First “culture shock” in my first week

It’s common for students to converse with one another in between assignments. I soon noticed a different rhythm in the office: people were focused on their tasks at hand, schedules were packed, and even brief chats had a purpose. The tone for the upcoming months was established by this observation.

I came to see that technical proficiency was not the only requirement for success in a business setting. It also involved developing trustworthy solutions, communicating effectively, and collaborating with busy stakeholders.

For me, this internship was a literal learning experience as I had no prior corporate experience. I discovered how engineering decisions are shaped by restrictions, how a vast organization transforms strategic goals into daily tasks, and how much "good data" relies on discipline and validation rather than flawless inputs.

A quick look at my day-to-day

I met with my supervisor every morning at 9:30 a.m. to discuss priorities and resolve any obstacles and there was also a weekly stand-up with the whole data team on Tuesdays. After the standups, remainder of the day was devoted to carrying out the activities that were outlined, including creating and testing workflows, verifying data, developing scripts, etc.

Dify and JupyterLab, were my most used tools. Rapid prototyping with an AI workflow platform for one project followed by creating notebooks for testing and iteration for the other projects, was essential to my ability to produce work efficiently and consistently. Compared to other interns within DBS, I was lucky enough to work on 3 large scale projects where the usual number would usually be 1.

Project 1: Professional Investor (PI) classification automation using Dify

Why this project existed
Sales employees were required to examine client paperwork, extract pertinent information, and categorize clients according to pre-established standards for investors. As this work was done manually, it was susceptible to common problems like typographical errors, missing information, and uneven interpretation; risks that are much more significant in a regulated setting than in a regular consumer scenario.

Problem Statement
How can we assist sales staff in using client data efficiently while lowering operational risk and human error through automation?

What I built
I built a conversational application using Dify, an open-source platform for agent-based workflows driven by large language models (LLMs). The system handled two broad input types:

1. Client financial records (e.g., statements or balance sheets)
2. Client background information (e.g., organizational context and details about investment decision-makers)

If I could highlight one lesson from this project, it would be this: in enterprise settings, success depends less on “how powerful the model is” and more on “how well you control the workflow.”

Instead of relying on one large prompt and one LLM call to do everything, I designed the application as a modular, multi-agent workflow with four main stages:

1. Initialization: onboarding, context setup, and input preparation
2. Classification: determining the correct category based on business rules
3. PI Form Filling: populating the required form fields with extracted information
4. PI Letter Generation: updating values within a standardized letter for review before sending

The sequence was controlled by a router agent, and context was preserved between turns via a conversation history block. The workflow operated in the aforementioned sequence by default, but I also allowed for user flexibility, such as letting users change the order in which they filled out forms and generated letters.

Example Rule
The two primary categories differ in which "sections" must be met, but they have identical classification requirements. In this use-case one category simply needs to meet Section A requirements, while another needs to meet both Section A and Section B requirements. I found early on that it was more difficult to control and explain the results when the entire classification was treated as a single, cohesive judgment.

So, I split the classification into two separate analyses: one agent evaluated Section A, another evaluated Section B, and a final decision layer combined the results according to the rules. This decision achieved three things:

• Stronger control over model behavior, because each agent had a narrower scope
• A more linear and auditable flow, because intermediate reasoning could be inspected
• Better efficiency and cost management, because the workflow reduced reliance on a single heavy LLM call

In other words, I didn’t try to make the model “smarter.” I redesigned the process so the model could be “safer.”

Ownership and responsibility
I developed this project from start to finish. I created and improved the prompts, developed the process logic and routing, established the agent architecture, and conducted iterative testing. The project’s broad direction was set by my supervisor, but I was solely responsible for its implementation and execution.

Stakeholder involvement was one aspect that I really appreciated. I had direct conversations with salespeople to learn about their expectations, challenges, and present workflow. Practical decisions, such as how stringent the guardrails should be, what the outputs should look like, and
when the algorithm should seek for clarification rather than guess, were influenced by their input.

How I improved accuracy from early prototypes to deployment-ready
The classification accuracy in early testing was just about 47%. That was a humble moment, particularly because it made me realize that early prototypes frequently "look like they work" until they are thoroughly tested.

Improving performance was an iterative process involving:

• Prompt refinement to reduce ambiguity
• Workflow restructuring to ensure prerequisite checks happened before decisions
• Adding safeguards for unclear cases
• Handling edge cases more explicitly

Accuracy in test cases we could access increased to over 85% by the end of the internship. I took cautious design decisions to lower risk in ambiguous circumstances because some critical edge scenarios could not be investigated due to confidentiality restrictions.

Get Daarmi Sai Lanka’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

The moment I felt I was truly contributing
The most memorable moment was when other regions expressed interest in the project and requested similar solutions for their own workflows. It was the clearest signal that what I built was not just a prototype, it was something valuable, useful & transferable.

Project 2: Data preparation for a Revenue Dashboard

Why this project mattered
The second major project supported senior management’s need for a centralized revenue dashboard. Prior to this project, numbers were dispersed among several teams and published at various periods, making it difficult for management to obtain a cohesive picture of performance. Furthermore, manual reconciliation was frequently necessary due to discrepancies between Finance’s official figures and business-generated data.

My scope concentrated on the data preparation and validation layer, the cornerstone required for any dashboard to be trusted, as the project was still in its early stages and I encountered considerable delays in acquiring data access (about 3 months)

What I built
A key piece of work was ingesting Finance data for monthly reconciliation. At the beginning of each month, an Excel file needed to be processed and persisted into the bank’s internal data structure.
I built an automated pipeline using:

• Python to orchestrate the end-to-end workflow
• PySpark to transform and persist data at scale while meeting enterprise standards
• SQL to validate ingestion results, schema alignment, and reconciliation readiness

Verifying record counts and completeness, ensuring that crucial fields were appropriately mapped, ensuring that data was arranged for effective querying, and supporting checks against Finance "true-up" statistics were all examples of validation tasks.

The bigger lesson from this project
I learned from this project that, when done correctly, data effort is frequently invisible. Even while a dashboard has an outstanding appearance, it becomes a liability if the underlying dataset is inconsistent, unvalidated, or difficult to refresh. Strong validation practices, meticulous attention to detail, and ease with repeated checks that shield downstream users from errors are all necessary for building a dependable pipeline.

Project 3: DBS_GPT upgrading

Team-specific instances and structured testing

What the upgrade aimed to solve
The breadth of a bank-wide knowledge base may cause responses to become excessively generic or loud. The goal of the DBS_GPT upgrade was to enable other teams to implement their own tailored versions of the internal LLM platform, limited to documents and datasets that are
pertinent to the team.

By restricting each instance to domain-specific data, lowering response noise, and enhancing usability for daily operations, the objective was increased response relevance and accuracy.

My role: testing with a “trust and safety” mindset
Testing and assessment were the main topics of my job. To determine whether outputs were precise, pertinent, and in line with user expectations, I examined replies in a variety of contexts. I especially searched for:

• Answers that pull from the incorrect scope are examples of irrelevant retrieval.
• Contradictions or insufficient responses
• Hallucinations (confident yet inaccurate results) Overly general answers that seem beneficial but aren’t practical
• I also offered suggestions on how to enhance the testing procedure itself, including what kinds of questions and failure scenarios should be given priority by upcoming testers.

What I learned from this project
This was my closest encounter with the responsible implementation of AI systems in a controlled environment. It reaffirmed that assessment is not an afterthought. Prior to broader implementation, testing requires organization, risk awareness, and clear expectations of what constitutes "acceptable."

The challenge I didn’t expect: Communication
Writing scripts and learning Dify weren’t the most challenging aspects of the internship. It involved managing communication. There were times when someone had to respond for a decision or access approval to be made, and they might not have time, forget, or miss the message.

I realised that I had to be proactive and persistent by sending succinct emails, following up with brief reminders, and maintaining a clear record of what was required and why.

A mindset that shaped everything: Always ask ‘Why?’
One piece of advice from my supervisor stuck with me: always ask "Why?", to grasp the rationale behind work, not to question directions. As I gained more knowledge, I was able to learn more quickly and make tasks easier in the future by applying what I had learned rather than approaching each task as a novel one.

Skills to build

If you’re aiming for a data/AI internship in a bank or similar environment, here are the skills that made the biggest difference:

• Structured Python problem-solving: breaking workflows into steps, writing maintainable logic, and iterating safely
• PySpark: utilized for processing and transforming huge datasets in a scalable manner (generally used to save data into databases in Parquet file format)
• SQL for validation: not just retrieving data, but verifying counts, schemas, and consistency
• Data engineering fundamentals: ingestion, transformation, persistence, and reproducibility
• Applied GenAI workflow design: controlling model behavior with modular design and guardrails
• Stakeholder communication: writing concise messages, confirming requirements, and following up responsibly

Where this experience takes me next

My preference for working closer to the AI engineering side over traditional software engineering was validated by this internship. I’m more at ease with disciplined workflows, logical reasoning, and creating systems that function dependably under pressure.

More significantly, it provided me assurance that you can make a significant contribution even if you have no prior business experience, if you maintain your curiosity, create feedback loops, and adopt a growth mentality. There is a learning curve, but there is also development.

My main piece of advice for someone starting their first internship is straightforward: be proactive in figuring out the "why," communicate persistently, and view every obstacle as a component of the design challenge rather than a reason to give up.

Acknowledgments

Thank you to my supervisor and the Global Financial Markets (GFM) Data Team at DBS for their guidance, patience, and support throughout my internship. I am also grateful to the sales stakeholders and internal users who shared their workflows and feedback, which helped me design solutions grounded in real operational needs.

All opinions and interpretations are that of the writer, and not of MITB. I declare that I have full rights to use the contents published here, and nothing is plagiarized. I declare that this article is written by me and not with any generative AI tool such as ChatGPT. I declare that no data privacy policy is breached, and that any data associated with the contents here are obtained legitimately to the best of my knowledge. I agree not to make any changes without first seeking the editors’ approval. Any violations may lead to this article being retracted from the publication.