Corporate Actions at BNP Paribas

The product was a legacy corporate actions processing system, a long-lived piece of BNP's Global Markets infrastructure serving two very different rooms. On one side, the arbitrage trading desk. On the other, prime brokerage clients, banks, insurers, and other institutions, each with their own elections to make.

The system worked. People had frustrations with it, but they were the kind of frustrations a team learns to live with. The automation opportunities visible to everyone were treated the way most teams treat them, as a list of small wins to pick off one by one.

The team had a packed backlog and no headcount approval. A redesign meant absorbing the discovery, framing, and solutioning work on top of the usual delivery rhythm, sprints, retros, smaller requirements, the team itself. The codebase carried a decade of business logic, much of it written by people no longer on the team, much of it undocumented. And engineering, already running at capacity on small fixes, had a tempo nobody wanted to disrupt for a year-long bet.

The obvious move was the one the team was already making, document the manual touchpoints, ship them as small enhancements, work through the backlog. I argued the opposite, in three pitches shaped to three audiences.

To business leadership, a long-term bet, a year of foundational work that would make every future change faster and the whole product cheaper to run. To tech leadership, tech debt, maintainability, a stack moved forward. To the users themselves, the arbitrage desk and the prime brokerage operations, it was their own time back, every manual touchpoint a meeting, a sign-off, a sprint validation on someone else's clock.

When leadership asked to reduce scope mid-project, I brought it back as a cost-to-value question with numbers. They were convinced. The position held.

The risk surfaced once engineering started looking at what a real rebuild would take. The undocumented decade of logic in the existing codebase had to be carried forward without losing edge cases nobody could fully describe. A full rewrite as code was not viable. The team would never finish reverse-engineering the legacy.

The rule engine emerged here, as the response. Logic would not be rewritten, it would be lifted forward as configurable rules, ordered, named, and inspectable. What was understood became explicit. What was uncertain became a rule the team could flag, isolate, and validate against production behaviour. The redesign survived because the solution stopped asking engineering to do something that could not be done.

Straight-through processing moved from 38% to 82% in the year following deployment. CSAT lifted from 73 to 81, mostly because the manual touchpoints had been the friction the score was tracking, and the redesign removed them at the source. The operations team got roughly 1,800 hours back annually, close to a full FTE of operations work, plus an unmeasured but larger reduction on the customer side.

The second-order outcome was not in the pitch. Engineering velocity climbed after the rule engine was live, because features that used to require code changes, QA cycles, and deployment now landed as rule changes. The redesign repaid the bet faster than the original pitch had promised.