Corporate Actions Processing Software Problems: The 7 That Turn Into Client Compensation, and How to Avoid Them

Why does trying to cover every event type and market at once fail so often?

The biggest scope failure in asset servicing builds is treating event type coverage as the objective. Teams list every corporate action type in existence, multiply by every market they touch, and produce a specification that will take two years and will still miss the exotic event that appears in month three.

This is precisely the ground where vendor platforms are strong. Broadridge, SmartStream, FIS XSP, Gresham and SS&C carry deep event type coverage and message handling built over decades, and recreating it is expensive and pointless. What every user of those platforms will tell you is that they still run a scrub team, because announcements arrive from several sources with conflicting terms and the decision about what is true stays manual, as does the exception handling on every voluntary event.

So the scope that pays is narrower than the one people write. Announcement reconciliation, deadline chain management, election intake from every channel your clients actually use, and the evidence trail. Cover your top two or three markets by event volume properly and leave the long tail on the existing process for a phase, because the tail holds the exotic events and it is not where your risk concentrates. A first release on that footing runs $105,000 to $230,000 and ships in 16 to 22 weeks in our delivery experience. A specification that starts with a taxonomy of every event type will not ship at all.

What goes wrong when you migrate announcements and reference data?

The migration failure in this category is structural rather than volumetric, and it happens on day one of design if nobody catches it. Most teams flatten announcements on arrival. Four sources come in, an analyst decides what is true, and one record is stored. Everything after that inherits a decision with no evidence behind it.

The consequence surfaces when terms are amended, which happens routinely and sometimes after clients have already elected. If the announcement was overwritten rather than versioned, you cannot reconstruct what you communicated and when, which is exactly the reconstruction a disputed event demands. The client remembers the original terms. You need to show the original notification, the amendment, the re-notification and the revalidation of existing instructions. A design that updates the event in place makes that impossible, and no amount of later logging repairs it.

Store every source as a separate versioned announcement. Compare them field by field, agree automatically where all sources match, and raise only the fields in conflict with the sources side by side and the analyst's decision recorded against the field. That structure also turns the question of which vendor is right for which market and event type into data rather than folklore, so you can auto resolve more each quarter with evidence.

The second migration trap is standing instructions and client contacts. Election notifications go to contacts held in a customer relationship system, a client static database and sometimes a spreadsheet, and they disagree. Reconcile those before go live, not after, because a stale contact is the single most common route to a compensation payment and it is a data problem rather than a software one.

Why do depository, custodian and market data integrations break after launch?

Integrations in asset servicing rarely fail loudly. They fail by dropping a message and continuing, which is worse.

The specific breakages recur. Message standards move: firms typically need both ISO 15022 and ISO 20022 formats and will run them in parallel for years, so a build supporting only one is scoped for a world that does not exist yet. Custodians send proprietary files that change layout with little notice and no versioning, which is usually the most annoying integration in the whole project and the one least likely to be estimated properly. Vendor announcement feeds normalise differently from each other and occasionally change their normalisation, which quietly shifts your golden record logic without anyone noticing.

Then there is the silent revocation problem. An instruction is submitted, the acknowledgement never arrives, and nothing raises it because the system logged the send. Weeks later a client is not taken out of an offer they elected for. Every outbound instruction needs an expected acknowledgement with a timer, an alert when it does not land, and a reconciliation of instructed against acknowledged positions before the market deadline rather than after it.

Design for supervision rather than for the happy path. Every interface should publish a heartbeat and a daily count that operations checks, so a feed that stopped on Tuesday is discovered on Tuesday. This is dull engineering and it is the difference between a platform your operations team trusts and one they shadow with a spreadsheet.

What happens when market claims and tax handling are not covered?

Two gaps get deferred to phase two more often than any others, and both come back as a steady drip of small corrective payments that consume more operations time than the events themselves.

Market claims are the first. Entitlement is not a simple ratio on a settled long position. Trades in transit across record date, fails, partial settlements, securities out on loan where the entitlement follows the borrower, multiple share classes, and beneficial owners holding across several accounts all change the answer. If claims are treated as a follow up task rather than a first class output of the entitlement calculation, they get worked manually and inconsistently. This has become more pressing since the move to a shorter settlement cycle in the United States compressed the window in which trades around record date resolve, which changes both claim volumes and their timing.

Tax is the second. Withholding, relief at source and reclaim processes vary by market and by treaty, and they are a specialism rather than a feature. Firms that leave tax out of the first release generally do so deliberately and correctly, but the trap is not scoping it out, it is scoping it out without designing the data model to accept it. Beneficial owner tax status, documentation validity dates and treaty rates have to be modelled at the position level from the start, because retrofitting them means reworking the entitlement calculation everything else depends on.

The honest sequence is to build entitlement over real position states with claims as a native output in release one, and to leave tax processing for a later phase while reserving its shape in the model.

Should you build custom or configure what you already own?

Buy, and do not build, if you are a smaller institution holding mostly domestic securities with predominantly mandatory events, or if you can push the servicing burden to a custodian who does it well. Nobody should build a corporate actions platform to process dividends and stock splits, and any developer who encourages it is not on your side.

Configure what you own if your vendor platform's gaps are workflow gaps you can close inside it. Many firms have more configuration headroom in Broadridge or SmartStream than they realise, and a serious internal review of what the platform can already do is cheaper than any build.

The realistic pattern for larger firms is to build alongside a vendor rather than instead of one. The vendor keeps event type coverage and message handling, where it is genuinely strong. You own announcement reconciliation, the deadline chain, election intake and the evidence trail, which is where firms actually lose money and where every vendor leaves you to your own devices. That layer also survives if you change vendor later, which is a strategic argument as much as an operational one.

Build when two or more are true. You process more than a couple of hundred voluntary events a year. Your scrub team spends more time reconciling announcement sources than servicing events. You have paid a client compensation for a missed election or a wrong entitlement in the last two years. You service clients across multiple markets with different deadline chains. Or you cannot show, for a specific event last quarter, exactly who was notified, when, and what came back.

How do hidden costs get into the quote?

Corporate actions quotes are underestimated in a consistent set of places, and market coverage is the largest of them.

• Market count treated as configuration. Each additional market brings its own conventions, calendars, deadline chains and tax treatment. This is the single biggest driver and it is frequently priced as a settings screen.
• One message standard scoped instead of two. Supporting both ISO 15022 and ISO 20022 is real work and most firms need both for years.
• Custodian proprietary files counted as one integration. Layouts change without notice or versioning, and this is usually the most irritating interface in the project.
• Securities lending left out. Recalls and claims arriving in scope later means reworking the entitlement engine rather than adding a module.
• Announcement source count. Each source has a distinct shape and error profile, and reconciliation logic is per source rather than generic.

The full platform adding client election channels, depository instruction messaging, market claims, tax withholding and relief at source, accounting and cash postings, and reconciliation of expected against received proceeds runs $290,000 to $780,000 phased over 10 to 18 months.

What separates a build that works from one that fails here?

The builds that work absorb the way clients actually behave rather than the way the portal designer hoped they would. You build a portal, half your clients use it, the rest email, some call, one large institution sends a file in its own format, and an internal portfolio manager instructs by chat message. The design that survives treats the instruction as a single object with several intake paths and identical validation on all of them, with structured extraction turning emails and documents into a draft instruction a human confirms and the original attached to the audit trail. Every instruction is validated against the holder's eligible position at that moment, because over elections rejected by the market after your deadline are the second most common source of corrective payments.

Deadlines are computed rather than remembered. Market deadline, custodian cutoff, internal cutoff and client cutoff, each with its own buffer rule and holiday calendar per market. Escalation is stepped rather than a single reminder, unresponded holders are chased on a schedule, and every voluntary event carries an explicit default action agreed with the client in advance so a non response produces a considered outcome rather than an accident.

And the evidence trail is complete enough to settle a dispute two years later without anybody reconstructing anything. Ask a prospective developer to model an event on a whiteboard. You want to hear versioned announcements from multiple sources resolving into a golden record, an options structure for voluntary events, a deadline chain with buffers per hop, and entitlement calculated over position states. If they describe an event as a row with a ratio, they will get the middle right and every edge wrong, and the edges are where the money goes.

Settle ownership of the code, the reconciliation rules and the cloud accounts in the contract before kickoff. At Digital Heroes the client owns all of it from the first commit.