E3

Capabilities

What E3 does today,
and what it is still being built to do.

Stated as two columns rather than one, because the distance between them is the thing a buyer needs and the thing vendors usually hide. Current as of the September 2026 capability review.


How evaluations work today

Sample, synthetic or de-identified files

Evaluations run on sample, synthetic, redacted or appropriately controlled historical loan files. That is deliberate, and it is how most serious enterprise evaluations begin in any case: it produces a meaningful measurement quickly, needs no change to systems already in production, and lets a lender compare our findings against quality control outcomes they already know.

Use involving live borrower personal information follows completion of the security, privacy and customer controls programme now underway. Security and compliance certification is a current company priority; ask where it stands and we will tell you, with dates where we have them.

E3 runs today in a riTara-managed cloud environment. Customer-controlled private cloud and on-premises deployment, with files remaining inside your environment throughout, is on the roadmap. Where you need to be on that path shapes the timing conversation, and it is worth having early.


Running today

The core workflow, end to end

These run in the deployed environment now. A rules specialist or an audit lead can be shown them without qualification.

INTAKE
Loan files processed end to end
Upload sessions, documents and run relationships, processing a complete package rather than isolated documents.
CLASSIFY
Segmentation and classification
Documents identified and split across the supported form set, with review of unclassified pages.
EXTRACT
Fields read, with confidence retained
Values extracted with confidence captured, low-confidence values highlighted for inline correction.
VERIFY
Reviewers correct what the system is unsure of
Human judgement stays where the system is uncertain, before anything downstream runs.
SYNTHESIZE
One structured loan record
Borrower, property, income, asset and liability structures consolidated, with conflicting values flagged and derived values shown.
VALIDATE
Versioned rules produce findings
Rule execution with severity, rule-level detail, and the findings workflow.
DISPOSITION
A named reviewer decides
Loan-level disposition captured with the deciding reviewer recorded. E3 produces findings; a person decides.
REPORT
A quality control report with export
Produced today. Investor and regulatory reporting packages are target, not current.

The strongest part

Rules, versioning and lineage

This is where the current state sits closest to the target, and it is why a controlled evaluation produces a meaningful result while the surrounding platform is still being completed. The rule model, execution, explainability and lineage can be demonstrated now; the authoring and approval interfaces around them are in the group below.

RULE SETS
Versioned, with explicit relationships
Rule sets, rules and versions implemented, so a finding can name the version that produced it.
PROGRAMMES
Programme to rule-set mapping
Loan programmes map to rule sets, so different programmes run different rules.
EXECUTION
Execution plans, results retained per run
So a run can be reconstructed rather than described.
EXPLAINABILITY
Rule logic shown with the outcome
Results carry the logic alongside the result and link back to the rule.
LINEAGE
Back to the source document
Findings and synthesized values retain lineage to the source data and documents.

Implemented, awaiting verification

Built, not yet demonstrated end to end

Distance to target and verification status are different questions. Everything in this group is implemented; what it has not yet had is demonstrated behaviour we would put in front of you as evidence.

APPROVAL QUEUE
Data model implemented, interface to demonstrate
Role-based approval rights and change history are target.
RULES CATALOG
Metadata modelled; catalog interface to verify
Usage analytics and impact analysis are target.
RULE STUDIO
Input mapping and testing designed in
An authoring experience usable by a rules specialist without engineering support is target.
NEEDS DATA / NOT APPLICABLE
Designed into the model, live behaviour to demonstrate
Recording that a rule did not run, so “no finding” and “not checked” stay distinguishable.
SCHEDULED RUNS
Configuration present, end-to-end behaviour to demonstrate
Retry, failure handling and alerting are target.

In development

Where the platform is extending

The areas below are where current and target are furthest apart. They are stated here so timing can be planned rather than discovered.

DEPLOYMENT
riTara-managed cloud environment today
We are building a Terraform deployment that stands E3 up inside a customer's own AWS account. Not available yet; it is the work that closes the two rows below.
DATA RESIDENCY
Documents are processed in the riTara environment
Under the deployment above, loan files and the processing that reads them would stay inside your account. That is the destination, not today's position.
INHERITED CONTROLS
Our controls today, yours after that change
Deployed into your account, E3 sits behind the network boundaries, key management, logging and identity controls you already operate and have already had audited. That is a materially different security conversation from the one available now, and it is the reason the work is prioritised.
TENANCY
Tenant-aware data model
Enforced end-to-end isolation, tenant administration and cross-tenant negative testing are target.
ACCESS CONTROL
Token-based login with session handling
Role-based access control, single sign-on and enforced authorization boundaries are target.
REVIEWER WORKFLOW
Reviewers inspect and correct values today
Queues, assignment, escalation and service levels are on the roadmap.
OBSERVABILITY
Application-level run metrics
Infrastructure observability, alerting and security detection are target.
RESILIENCE
Standard managed database and storage services
Defined availability and recovery objectives with tested backup and restore are target.

Two things that are not gaps

Deliberate positions, not unfinished work

A person makes the decision. Reviewers correct extraction, assess findings and make the final loan decision. That is a design position and it is not on a roadmap to be removed.

Pricing is not a per-page fee. Underlying cloud and model consumption is variable, so the economics of review do not change simply because a file got longer.

See where it stands, on a real file.

A working session on a synthetic file, or de-identified files of your own. You will see the parts described above as running, and the parts that are not.