Verify ownership, identify risk, and uncover title-related fraud before capital is committed.
A shared, tamper-evident intelligence network that helps financial institutions verify property interests, surface title risk, and protect property-backed transactions.
Sign in with your organization-issued credentials to continue.
New user? Accounts are provisioned by your institution's SIRMS administrator.
Search by L.R. number, grant/I.R. number, or deed plan number across the shared registry and connected institutional records.
Filing to open or release a lock now only submits a request — a different officer with the approver role at your bank has to decide it in the Approvals tab before it actually happens. The duplicate-lock demo below still attacks the database constraint directly, unchanged.
Filing to register or discharge a charge now only submits a request, same as locks above. Run "pre-disbursement check" in the Title & acting bank card above once the request has been approved in the Approvals tab, to see the gate flip.
Real segregation of duties: whoever filed a request above cannot be the one who decides it, even if they're logged in as someone else in another tab. Only an officer holding the matching role (approver for locks/charges, registrar for deed instruments) at the same bank can act here — and never on their own filing.
Write access here is Secretariat-only: a neutral party with no stake in any given title's history, never a member bank. Every entry must cite a source document, and two different registrars still have to sign off (in the Approvals tab) — maker-checker all the way down.
Check first whether this title's deed is already on file in SIRMS — from any prior loan origination, at this bank or another member bank — before typing anything by hand. Loading it fills in Document reference and Record a deed instrument below for you to check and correct; nothing is ever filed without a second registrar's approval, loaded or typed.
"Network repository" would pull a deed a bank holds in its own private records from before SIRMS existed — that needs every bank to agree on access rules first, so it's disabled here on purpose.
The grant-level facts transcribed straight off a physical deed's own header/registration section — L.R. number, Grant/I.R. number, plan number, tenure, term, rent. This creates the title_record row itself, so it has to exist before anything else below can reference it. Submits for approval like everything else here; a second registrar must approve it in the Approvals tab, and it'll then appear in the title list above.
The proprietor's own personal details, shown as they currently stand — deliberately placed before the chain-of-custody entries below, since this is the answer most people actually want first. ID numbers are hashed, never stored raw; recording or updating this goes through the same two-registrar approval queue as everything else here.
Cite the physical document being transcribed. This is a direct record of "this document exists" — it doesn't assert anything about the title's history yet, so it doesn't go through the approval queue.
Identifying fields (marked *) are mandatory — an entry with no presentation number or registration date isn't traceable back to the actual deed. This submits for approval like the Application Lock and Charges tabs; a second registrar must approve it in the Approvals tab.
Answers a specific question — how many times has this title changed hands, from whom, to whom, and when — filtered down to only the instrument types that actually move ownership (transfer, assent, grant of letters of administration). This is the register a loan officer or investigator would actually want, separate from the full mixed timeline below.
The deed's own endorsement register, interleaved with SIRMS's own ledger events for this title — oldest first.
Write access here is Secretariat-admin-only, and every change — creating an officer, granting a role, revoking a role — still goes through the same maker-checker approval queue as everything else: a different admin has to decide it in the Approvals tab before it takes effect. Everyone can browse the roster below.
Every officer across every member bank and the Secretariat, with their current roles and employment status.
Provisions a new bank/Secretariat employee record. Submits for approval like everything else here — a second admin must approve it before the officer can log in. (No role is granted yet; use "Grant a role" below once the officer exists.)
Segregation of duties still applies: a bank officer should hold exactly one of originator/approver, and only Secretariat officers should hold registrar or admin — the app won't stop you from granting an unusual combination, but the approving admin should check before approving.
Ends an officer's ability to act in that role going forward. Also submitted for a second admin's approval before it takes effect.
Paste an event_id from the history above (Title & acting bank card → "Load ledger history") and try to edit it directly with SQL. It should be blocked by the append-only trigger, not by application code.
Every read, not just every write, leaves a hash-chained, retrievable trace.