Putting It All Together: A Banking Case Study

The Scenario

A mid-tier European bank's corporate actions department processes approximately 15,000 mandatory events per year across equities, fixed income, and structured products. These events include dividends, stock splits, mergers, and bond redemptions — each requiring accurate, timely processing to ensure clients receive their entitlements and settlements complete without failure.

Over the past twelve months, the department's on-time processing rate has dropped to 72%, well below the internal SLA target of 95%. The consequences are serious: failed settlements incur penalty charges under CSDR, client complaints have increased by 40%, and the compliance team has flagged the department for heightened operational risk. The Head of Securities Operations sponsors a DMAIC project to address the problem.

This case study walks through every phase of the DMAIC cycle, showing how the tools and techniques from the previous modules come together in practice. As you read, consider how a Yellow Belt on the team would contribute at each stage.

Define: Scoping the Problem

The project team — a Green Belt project lead, two Yellow Belts from the corporate actions desk, a technology analyst, and a representative from custody operations — began by drafting a project charter.

The charter defined the problem statement: "Mandatory corporate actions are processing on time at a rate of 72%, against a target of 95%. This results in failed settlements, CSDR penalties, client complaints, and increased operational risk." The goal was clear: improve the on-time processing rate from 72% to 95% within six months.

The team then created a SIPOC diagram to map the process at a high level:

• Suppliers — Market data vendors (Bloomberg, SWIFT), issuers, depositories, and internal front office teams
• Inputs — Corporate action notifications, security reference data, client holding positions, payment instructions
• Process — Notification receipt, event setup, entitlement calculation, instruction generation, settlement
• Outputs — Processed corporate actions, settled entitlements, client confirmations, regulatory reports
• Customers — Institutional clients, custody clients, internal trading desks, compliance, regulators

The SIPOC immediately highlighted the complexity: multiple external suppliers feeding into a multi-step process with diverse internal and external customers. Stakeholder mapping identified the custody team, compliance, client relationship managers, and the CTO as key parties to engage throughout the project.

Measure: Establishing the Baseline

The Yellow Belts on the team played a critical role in the Measure phase. They were the people closest to the daily work and understood which data was reliable and where the gaps were.

The team created a current-state process map that documented every step from notification receipt to final settlement. The map revealed 23 distinct process steps with 6 handoffs between teams and systems. Several steps involved manual data entry from PDF notifications into the processing platform — a pattern that immediately stood out as a risk area.

Data collection over a three-month baseline period produced the following metrics:

• On-time processing rate: 72% (target: 95%)
• Mean cycle time: 6.2 hours (specification limit: 4 hours)
• Standard deviation of cycle time: 2.8 hours
• Process capability (Cpk): 0.24

A Cpk of 0.24 confirmed what the team suspected: the process was severely incapable. With a mean cycle time exceeding the specification limit and high variation, a large proportion of events were inherently likely to breach the SLA even on an average day.

The team also developed an operational definition for each metric to ensure consistency. "On-time" was defined as entitlement settlement completed by the market deadline for the relevant depository — no ambiguity, no interpretation.

Analyze: Finding Root Causes

With solid baseline data in hand, the team moved into structured root cause analysis. They ran a Fishbone (Ishikawa) workshop with eight participants from operations, technology, and custody. Potential causes were organized into four categories:

• People — Training gaps on complex event types, inconsistent processing practices between shifts, over-reliance on a small number of experienced staff
• Process — Manual data entry from vendor notifications, sequential processing (no parallelism), unclear escalation paths for late notifications
• Systems — No automated data feeds from key vendors, aging platform with limited straight-through processing, no proactive alerting for missed deadlines
• External — Late or incomplete notifications from issuers and depositories, inconsistent data formats across vendors

The team then applied 5 Whys to drill into the most frequently cited cause — manual data entry errors:

1. Why are events processed late? Because data entry takes too long and contains errors that require rework.
2. Why does data entry take too long? Because operators manually transcribe details from PDF notifications into the system.
3. Why is data entered manually? Because the bank has no automated data feed for corporate action notifications.
4. Why is there no automated feed? Because the integration was deprioritized in previous technology budgets.
5. Why was it deprioritized? Because the operational cost of manual processing was never quantified until now.

This 5 Whys chain traced the symptom (late processing) to a fundamental root cause (absence of automated data ingestion) and exposed the organizational reason it persisted (lack of visibility into the true cost).

The team then built a Pareto chart from three months of failure data, categorizing every late or failed event by root cause. The results were striking:

• Manual data entry errors — 45% of all failures
• Late vendor notifications — 30% of all failures
• Unclear escalation paths — 12% of all failures
• System downtime — 8% of all failures
• Other — 5% of all failures

Two root causes — manual data entry and late notifications — accounted for 75% of all processing failures. This focused the team's improvement efforts on the vital few rather than scattering energy across every possible cause.

Improve: Designing and Testing Solutions

Armed with validated root causes, the team brainstormed solutions and used a prioritization matrix to evaluate them. Three solutions emerged as the highest priority:

1. Automated data feeds — Integrate SWIFT corporate action message feeds (MT564/MT566) directly into the processing platform, eliminating manual data entry for the majority of events.
2. Early notification alert system — Build a proactive monitoring dashboard that flags when expected notifications from key depositories have not arrived by a defined cutoff time, triggering early escalation.
3. Revised escalation process — Create a clear, time-bound escalation matrix so that late or complex events are flagged to senior processors within one hour rather than languishing in a general queue.

Rather than implementing everything at once, the team designed a four-week pilot limited to equity corporate actions — the highest-volume asset class, representing approximately 60% of all events. The pilot defined clear success criteria: on-time processing rate above 90%, average cycle time below 4 hours, and zero data entry errors on automated events.

The pilot results exceeded expectations:

• On-time processing rate improved from 72% to 91%
• Average cycle time dropped from 6.2 hours to 3.1 hours
• Data entry errors on automated events fell to zero
• Operators reported significantly reduced workload stress and greater confidence in data quality

The team documented these results, captured lessons learned (including a matching rule adjustment needed for certain corporate action sub-types), and built a phased rollout plan to extend the solution to fixed income and structured products over the following quarter.

Control: Locking In the Gains

With the solution proven and rolled out, the team established a comprehensive Control framework:

A control chart tracked the daily on-time processing rate. The center line was set at 94% (the post-rollout average), the UCL at 98%, and the LCL at 90%. The team reviewed the chart every morning during their daily stand-up, and any breach of the LCL triggered an immediate root cause investigation.

The SOPs were completely rewritten to reflect the new automated workflow. The updated procedures covered the automated feed reconciliation process, manual fallback procedures for events not covered by automation, exception handling for late notifications, and the new escalation matrix. Every team member completed a training session, and the SOPs were stored in the team's shared knowledge base with a quarterly review cycle.

The process owner — the Corporate Actions Team Lead — formally accepted ownership of the control plan during a handoff meeting with the project team. A weekly review meeting was established for the first three months, then shifted to fortnightly once the process demonstrated sustained stability.

After three months of sustained operation, the results spoke for themselves:

• On-time processing rate: stable at 94% (up from 72%)
• Process capability (Cpk): improved to 1.1 (up from 0.24)
• CSDR penalty charges: reduced by 85%
• Client complaints related to corporate actions: down 70%

Your Role as a Yellow Belt

Throughout this case study, Yellow Belts were not bystanders — they were essential contributors. Here is what Yellow Belt team members brought to each phase:

• Define — Provided frontline perspective on the real pain points. Helped validate that the problem statement reflected what operators actually experienced daily. Contributed to the SIPOC by clarifying what inputs they received and from whom.

• Measure — Collected the baseline data. Because Yellow Belts operated the process every day, they knew which system reports were reliable and which manual records needed cross-checking. Their involvement ensured data quality.

• Analyze — Participated actively in the Fishbone workshop, contributing causes that the technology or management team would not have identified. Their practical knowledge of daily workarounds and failure patterns was invaluable during the 5 Whys analysis.

• Improve — Tested the pilot solution on the front line. Provided immediate feedback on usability, flagged matching rule issues, and suggested refinements that made the solution work better in practice.

• Control — Became the first line of monitoring. Yellow Belts review the daily control chart, flag exceptions, and follow the updated SOPs. Their ongoing engagement is what sustains the improvement long after the project team has moved on.

As a Yellow Belt, you may never lead a DMAIC project on your own — that is the role of a Green or Black Belt. But your contribution is irreplaceable. You are the bridge between methodology and reality, between data and daily operations. Every successful Six Sigma project in banking depends on Yellow Belts who understand the tools, engage with the process, and take ownership of the improvements in their area.

In the next module, you will complete the final exam to earn your Six Sigma Yellow Belt certification.