About
Written from a real back office and forty-three real files.
Registry did not start as a product idea. It started by reading how one RTA actually works and then parsing nine months of what its depositories actually sent — which turned out to disagree with the register in a way nobody had noticed.
Where the requirements came from
Three sources, in decreasing order of authority.
The SEBI regulations
What a registrar is obliged to do and how quickly. Turnaround times, periodic certificates, the complaints statement, the reconciliation of share capital audit, the IEPF clock. These set the floor: a feature that makes an obligation harder to meet is a wrong feature, however elegant.
A decade-old incumbent back office
Read screen by screen, covering two ISINs of a live issuer. This established the functional floor — what an RTA desk actually does all day, including the eleven separate list pages that Registry replaces with one queue that has state.
Nine months of real position files
Forty-three weekly beneficiary position files for one of those ISINs, parsed end to end. This established what the data actually looks like, as opposed to what a specification would assume.
What the real data changed
All 43 files carried producer-supplied control totals that matched exactly. Two of the 42 weekly transitions showed a net change in demat holding with nothing in the incumbent register explaining it — one of 1,28,16,000 shares and one of 31,000.
Two things follow from that, and both are in the product.
Control totals are a hard gate, not a warning
Forty-three out of forty-three matched. A file whose own producer disagrees with its contents is not a file worth loading, so gate two rejects it outright rather than flagging it for someone to look at later.
Continuity is a separate gate, and it does not reject
The position in those two files was real. What was missing was the explanation. Rejecting the file would have thrown away good data to hide a bad register — so gate four loads it and raises a break with an owner, an age and an explanation field. That is module M04, and that is the whole argument for building this.
Straight answers
Things a careful buyer should ask, answered before they do.
An RTA is buying the system that holds its registration. Vagueness on this page would be a bad sign about everything else.
Are you a SEBI-registered RTA?
No. rgs.plus licenses software to Registrars and Transfer Agents who hold that registration. We may apply for our own licence in future; until we hold one, we will not imply that we do.
Is Registry running in production today?
The specification is complete and the architecture is settled. We are candid on a call about exactly which phases are built, which are in build, and what a first engagement looks like. Ask directly — the answer will be specific.
Will you build automatic database failover?
Not by default. Patroni buys automatic promotion and also costs split-brain risk plus a component to operate on every node. Recommendation: start manual, add it for the Critical tier only, and only after a real drill.
How much of the machine-assistance is AI?
Document extraction and anomaly detection, in phase five, always behind a human approval step, with every suggestion and every confirmation logged. An RTA cannot defend an automated decision it cannot explain, so nothing decides on its own.
The company
rgs.plus
Registry is built and licensed by rgs.plus. All register data and backups remain within India. Our clients are SEBI-registered Registrars and Transfer Agents; each runs its own node, holds its own depository credentials, and keeps its own keys.
We would rather have a long first conversation than a short one. Bring your compliance officer and, if you can, a real position file.