Open Standard
An open mortgage evidence standard, in development with the ecosystem.
We are developing this standard with institutional participants, not alone. Once published, it will belong to the market: anyone will be able to implement it without Realworld. Until then, we work from the current working material directly with participants who want to review or help shape it.
Purpose
What the standard is for.
The same mortgage facts are established once and rebuilt many times, because the evidence for them is not portable. A valuation is authoritative in the valuer's report and retyped everywhere else. A registered charge is confirmed at completion and re-verified by every party that later relies on it. A balance is correct in the servicing system and approximate in every extract of it.
The standard exists so that a mortgage fact can be expressed, signed, verified and superseded in a common, open way, by the institution that is authoritative for it, and then relied upon downstream by any system that implements the standard. That includes systems Realworld has never touched.
Evidence should be reusable across institutional workflows, not repeatedly reconstructed. An open, interoperable standard is how that becomes possible across an ecosystem with many independent participants, not just within one company's systems.
Anatomy
What a piece of evidence carries.
Under the standard, a piece of mortgage evidence is not a document. It is a signed, structured assertion that answers the questions a recipient would otherwise have to ask by phone, by email or by re-performing the work.
Identity
What it refers to
The property, loan, party or charge the evidence is about, identified in a way that other systems can match without ambiguity.
Assertion
What it states
The fact being asserted: a value, a balance, an ownership position, a registered charge, a completion, a payment status.
Issuer
Who is authoritative for it
The institution that produced the fact (the valuer, the lender, the servicer, the completion or registry infrastructure) signing it at source.
Basis
On what basis and for what purpose
The methodology, the purpose for which the evidence was produced, and any conditions attached to relying on it.
Time
When, and whether it is still current
The date of issue, a source status reference, and what it supersedes, so an authorised recipient can check whether a position is still current or has been replaced.
Verifiability
How a recipient checks it
Provenance a downstream system can verify against the source, without a person re-establishing what has already been established.
Scope
The evidence domains.
Each domain is designed to be adopted independently. An institution can implement one, valuation evidence, say, without implementing the rest.
- Property and valuation: asset identity, value and basis, valuer, date, purpose, currentness and supersession.
- Borrower, identity and credit: where permitted, and only to the parties permitted to receive it.
- Loan terms, rate and balance: the commercial position of the loan as held by the system of record.
- Title and ownership: the ownership position as confirmed by the authoritative source in the jurisdiction.
- Charge and legal state: the registered charge and its legal status.
- Servicing, payments and arrears: current state from the servicing system of record.
- Lifecycle events: supersession, discharge and the events that change a loan's state over time.
- Permissions and consents: where a jurisdiction or a workflow requires them to travel with the evidence.
Openness
What is open.
The common evidence layer is designed to be open and interoperable, and Realworld does not own it. Each item below is planned so that, once published, no part of it depends on Realworld to be useful. Until publication, participants working with us review each as current working material.
The specification
The mortgage evidence standard itself: what evidence is, how it is expressed, signed, verified and superseded.
Schemas and data models
Machine-readable structures for each evidence domain, designed to be inspected before they are adopted.
Credential profiles
How an authoritative institution signs evidence at source so that a recipient can verify it.
Interoperability interfaces
How systems exchange evidence with one another under the standard.
Base conformance requirements
What an implementation must do to be considered conformant, so that "implements the standard" means the same thing everywhere.
Reference implementations and basic tooling
Working code, not just documentation: reference implementations and basic verifier and conformance tooling, where free access lowers the cost of adoption.
Design principles
How the standard is designed.
Where Realworld sits
The standard is designed to be open. Execution is what we offer.
Realworld does not own the standard. We aim to be the easiest, safest and most economical way to execute it in production, once it is ready for that.
A standard is only useful once it is running inside real institutional systems, and that is where the work is. Alongside the open standard, Realworld builds and operates the production execution that puts it to use: integrations and connectors to existing institutional systems, the mappings from each institution's own data to the standard's semantics, orchestration across systems, exception handling, conformance in production, monitoring and managed implementation.
That is how we intend to sustain ourselves: by making the standard work in production for the institutions that choose to work with us, not by charging for access to the standard itself. Anyone who prefers to implement it independently is free to, and we will still help them do so.
Implementation help
We will help you implement it.
We're prepared to invest engineering resources, build reference implementations, and help participants implement the standard directly. That applies whether you intend to work with Realworld in production or not: a more interoperable ecosystem is the objective, and every conformant implementation advances it.
- Review before you commit. Schemas, credential profiles and conformance requirements you can inspect with your own architects and risk teams first.
- Engineering alongside yours. Our engineers working with your team on the mapping from your existing outputs to the standard, rather than a specification handed over and left.
- A reference implementation to start from. Working code that demonstrates a conformant issuer and a conformant verifier, so that you are not starting from a blank page.
- Feedback into the standard. What you learn implementing it shapes the next revision. The standard belongs to the market, and the market includes you.
The specification, schemas, conformance requirements and reference implementations are published on this page as each becomes ready for public use. Until then, we work from the current working material directly with participants who want to implement or review it. Nothing is described here as published before it is.
Who should implement it
Anyone who produces or relies on mortgage evidence.
Valuers
Issue valuation evidence that stays attributed to you and is verifiable downstream.
For Valuers →Lenders
Consume evidence from source and issue loan-state evidence from your systems of record.
For Lenders →Servicers
Issue current loan state with provenance, under access rules you and the lender set.
For Servicers →Title & Completion
Express completion, charge and ownership evidence that names its authoritative source.
For Title & Completion →Assurance, TPR & Big Four
Consume structured evidence so existing checks start from the fact, not the document.
For Assurance →Standards & infrastructure partners
Align schemas and conformance with what you already operate; co-develop a reference implementation.
For Partners →Open protocol. Open ecosystem.
The standard belongs to the market. Let's make it useful.
Whether you want to review the specification, implement one evidence domain, or co-develop a reference implementation, the first step is the same.