Corporate Actions Processing Software: How Do You Stop a Missed Election Turning Into a Client Compensation Payment?

Why asset servicing errors are paid for in cash, immediately

A tender offer closes at 5pm New York on a Thursday. Your internal deadline was Wednesday noon, deliberately early, to leave room for stragglers. Twelve clients responded. One did not, and that client holds 400,000 shares. On Friday the stock trades below the tender price and the client calls to ask why they were not taken out. The answer is that the notification went to an email address the relationship manager updated three months ago in the customer relationship system and nowhere else. The difference is a compensation payment, and it is not disputed, because the record shows nothing went out.

Corporate actions is one of the few operations areas where an error converts directly into a payment to a client with no argument available. Wrong entitlement, missed election, late instruction, incorrect tax treatment: each one is quantifiable, and the client will quantify it for you. That is why asset servicing automation is one of the easiest business cases to write in securities operations, and also why it is so often half done.

Broadridge, SmartStream, FIS XSP, Gresham and SS&C all run real corporate actions platforms with genuine depth in event types and message handling, and they are used across the industry for good reason. What every user of them will tell you is the same thing: they still run a scrub team. Announcements arrive from several vendors and depositories with conflicting terms, and the process of deciding what is true remains manual, as does the exception handling on every voluntary event. The packaged system handles the events it recognises cleanly. Your operation is defined by the ones it does not.

Problem 1: the golden record is manual because the sources genuinely disagree

Two data vendors, a depository notification and the issuer agent's own document will differ on the record date, the ratio, whether fractional entitlements are cashed out, or the election deadline. The differences are not usually errors. They are timing, since terms get amended, and interpretation, since vendors normalise differently. An analyst reads all four and decides.

What a build changes is not that judgement, it is what surrounds it. Every source is stored as a separate versioned announcement rather than being flattened on arrival. The system compares them field by field, agrees automatically where all sources match, and raises only the specific fields in conflict, with the sources side by side and the analyst's decision recorded against the field. Over time the pattern of which source is right for which market and event type becomes data rather than folklore, which lets you auto resolve more each quarter with evidence rather than by feel. In the builds we have delivered, the share of events reaching an analyst falls significantly while the events that do reach one get more attention, which is the correct trade.

Problem 2: deadlines are managed backwards from the wrong date

The market deadline is not your deadline. Your client deadline has to sit before your custodian's, which sits before the depository's, which sits before the issuer agent's. Each hop needs buffer, and each has different cutoffs by market. Teams manage this with a shared calendar and instinct, and the failures cluster exactly where you would expect: a market with an unfamiliar convention, a holiday nobody checked, or a chain of custody with one more hop than usual.

A build treats the deadline chain as a computed structure per event: market deadline, custodian cutoff, internal cutoff, client cutoff, each with its own buffer rule and holiday calendar per market. Escalation is automatic and stepped rather than a single reminder. Unresponded holders get chased on a schedule, and the record of every notification, chase and non response is the artefact that protects you when a client says they were never told. Default handling matters too: every voluntary event should have an explicit default action agreed with the client in advance, so a non response produces a considered outcome rather than an accident.

Problem 3: entitlement calculation goes wrong in the edges, not the middle

The straightforward ratio on a settled long position is arithmetic anyone can do. The errors live in the edges. Positions in transit across record date. Fails. Securities out on loan where the entitlement follows the borrower and a claim is due. Partial settlements. Fractional handling that differs by market and by event. Multiple share classes. Positions held across several accounts for the same beneficial owner where an election minimum applies at one level and not another.

What a build must do is calculate from the position record with all of those states modelled explicitly rather than from a flat holdings snapshot, and generate market claims as a first class output rather than a follow up. Claims deserve particular attention now, because the move to a shorter settlement cycle in the United States compressed the window in which trades around record date resolve, which changes claim volumes and timing. A system that treats claims as an afterthought will generate a steady stream of small, irritating client credits that consume more operations time than the events themselves.

Problem 4: elections arrive by every channel except the one you built

You build a portal. Half your clients use it. The other half email, some call, one large institution sends a file in its own format, and an internal portfolio manager instructs by chat message to somebody's personal inbox. Each of those has to become an instruction with an audit trail before a deadline.

A build handles this by making the instruction a single object with multiple intake paths and identical validation on all of them, rather than a portal with exceptions handled manually beside it. Email and document instructions go through structured extraction into a draft instruction that a human confirms, with the original attached, so the audit trail holds the source document alongside the parsed result. Every instruction is validated against the holder's actual eligible position at that moment, because the second most common cause of a corrective payment, after a missed election, is an over election that the market rejects after your deadline has passed.

What this costs and how long it takes

A focused first release, meaning multi source announcement capture with golden record reconciliation, event and deadline modelling across your markets, entitlement calculation over positions including in transit and lending states, and an election workflow with escalation, runs $105,000 to $230,000 and ships in 16 to 22 weeks. A full platform adding client election channels, depository instruction messaging, market claims, tax withholding and relief at source handling, accounting and cash postings, and reconciliation of expected against received proceeds runs $290,000 to $780,000 phased over 10 to 18 months.

What drives cost up specifically here: market coverage, because each additional market brings its own conventions, calendars, deadline chains and tax treatment and this is the single largest driver; message standards, since firms typically need both ISO 15022 and ISO 20022 formats and supporting both is real work; securities lending, which brings recalls and claims into scope; tax, where relief at source and reclaim processes vary by market and treaty and are their own specialism; and the number of announcement sources you must reconcile, since each has a distinct shape and error profile.

What holds it down: covering your top two or three markets by event volume properly and leaving the long tail on the existing process for a phase. The tail is where the exotic events are and it is not where your risk concentrates.

Build versus buy, and when a vendor platform is right

Buy 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. Do not build a corporate actions platform to process dividends and stock splits.

Build, and usually build alongside a vendor rather than instead of one, when two or more of these 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.

Our position is that event type coverage is where vendors are strong and where building is wasteful, while announcement reconciliation, deadline chain management, election intake and the evidence trail are where firms actually lose money and where every vendor leaves you to your own devices. That is the layer worth owning, and it is also the layer that keeps working if you change vendor later.

How to choose a developer for corporate actions software

Ask them to model an event. You want to hear about multiple versioned announcements from different 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 rather than a holdings number. If they describe an event as a row with a ratio, they will get the middle right and every edge wrong.

Ask how they handle amendments. Terms change after announcement, sometimes after clients have already elected, and the system must re-notify affected holders, re-validate instructions and record the whole sequence. A design that overwrites the announcement makes that impossible to reconstruct.

Ask what they have integrated by name. ISO 15022 messaging, a depository connection, a market data vendor announcement feed and a custodian's proprietary file are four separate problems, and the last one is usually the most annoying.

Ask who owns the code, the reconciliation rules and the cloud accounts, and get it in the contract before kickoff. At Digital Heroes the client owns all of it from the first commit. When a client disputes an entitlement two years from now, the evidence that resolves it is the event history and the notification record inside this system, and that evidence needs to be somewhere you control absolutely.