Everything a lender needs to price, lock and govern its loans.

The four modules

• Company Manager. Client companies, regions, branches and users; broker (TPO) divisions; investors and their programs; and program subscriptions, the switch that decides what a client may ever be priced on.
• Program Manager. Guideline matrices for credit, LTV and CLTV, loan amount, DTI, reserves and MI; overlays; LLPA and SRP grids; and inheritance, so common rules are entered once and reused.
• Ratesheet Manager. Maps each investor's rate sheet layout (block or linear) to products, migrates it into base pricing, and holds each program's lock and extension policy.
• Utility Manager. FHFA and HUD loan limits, census tracts, AMI and Duty to Serve data from the official publishers, Federal Reserve index and rate series, and the lock desk's Rate Lock Directory.

How a program goes live

1. Define the investor and the program, with its channels and price files.
2. Build the guidelines and overlays that decide eligibility, and the LLPA and SRP grids that adjust price.
3. Map and migrate the investor's rate sheet. Show-Pricing lets the desk check the result before any loan sees it.
4. Subscribe the client companies that may sell the program. The engine considers it from the next quote.

Under the hood

Why it matters

A pricing engine is only as good as the configuration behind it. Manager makes that configuration explicit, owned and reviewable, so a lender can say exactly why a program priced the way it did on any given day, and who set it up that way.

One deployment can host many independent lending companies side by side, each with its own hierarchy and its own broker division, every record scoped to its owner.

A loan's journey

1. Submit. A guided form offers only the programs the client is subscribed to, and geocodes the address to census tract, county, AMI and Duty to Serve.
2. Eligibility. Six stages narrow every subscribed program to the program and product pairs that qualify. An overlay can only tighten a guideline.
3. Pricing. Base price, LLPA and SRP adjustments, ratesheet overlays and the lock period, then a best-execution ranking.
4. True BestEx. Rates down the side, products across the top, the best price in each cell. Every cell opens to its full breakdown.
5. Counter-offer. When nothing fits as entered, the engine relaxes one constraint and comes back with the best terms actually available.
6. Lock. The officer requests a lock from the grid, and the lock desk takes it from there.

What sets it apart

• Priced as of any moment. Every engine entry point accepts an as-of date, so a locked loan re-prices against the rules and rate sheet of the day it was locked.
• The code or the data? Loan Audit replays eligibility from the saved run, field by field, and names the guideline or overlay behind each result, even for a loan priced months ago.
• The whole instrument. ARM margins, rate caps and prepayment terms are resolved along with the price.
• Configured, not coded. Guidelines and overlays are authored as data, so a lender changes how the engines behave without a deployment.
• Credit-aware. For Non-QM loans, graded credit events filter eligibility before pricing runs.

From spreadsheet to bid

1. Upload a bid tape, a portfolio extract or a what-if set.
2. Map columns and coded values to loan fields once. The map is saved and reused for every tape in that format.
3. Process. Test one row's eligibility, price one loan in full, or run the whole set as a tracked, parallel job.
4. Review the dashboard: priced, failed, counter-offer and no-pricing, with weighted-average coupon, price, FICO and LTV.
5. Export a Bid Summary PDF grouped by plan type, each group carrying its own weighted averages.

Built for volume

• One engine. Each row becomes the same loan object the single-loan form builds, so a price on a tape is the price that loan would get on its own.
• Fast by design. Batch loans price at the note rate only, in parallel, with a fresh engine chain for each loan.
• No message broker to run. Large uploads queue in-process and price on a background worker while the screen shows progress.
• One bad row never stops a run. Rows with missing or unmappable values are reported against their spreadsheet line and skipped.
• Safe to re-run. Reprocessing against today's pricing can be cancelled, and cancelling restores the prior results.

On the phone

• Price a loan through a guided, validated wizard. Only the client's own programs appear.
• True BestEx as swipeable cards sized for a thumb.
• Counter-offer with ranked, achievable terms when a loan does not fit as entered.
• Loan Audit with pass or fail by program and the field-by-field reason, so an officer can troubleshoot anywhere.

Secured like the rest of the platform

• The same account, sign-in and two-factor flow as the web.
• Sessions refresh quietly in the background and log out after idle time, so a phone left in a pocket is not an open door.
• Each device carries its own refresh token, so signing in on one never signs another out.

Ways in

• The book. Written summaries of every area, layered by depth.
• Ask live. A conversation with eLCee that remembers what was asked before.
• Diagrams. Architecture for the technical reader, workflow charts for the operational one.
• Walkthroughs. Step-by-step help for any task.
• Code on screen. For technical evaluators, allowed code shown and explained, behind an access gate.

How it stays right

• eLCee reasons over the platform's own documents, never the open internet.
• What she reveals depends on the reader's access tier, and a hard guard keeps secrets and credentials out of every answer.
• When a question exposes a gap, the library is strengthened, so answers improve over time.
• Automated evaluation and adversarial tests run on every change.

The security model

• Single sign-on. One account spans the platform; every product and the API honor the token issued at login.
• Stateless two-factor. A short-lived signed token carries the "verified, awaiting code" state, so it works the same on web and mobile. Codes are hashed at rest.
• Per-session refresh. Each session rotates only its own refresh token, so devices never sign each other out.
• Claims carry capability. The token carries the user's roles, so each service enforces access from what it already holds.

Hardened by default

• No account enumeration. Sign-in, recovery and registration replies never confirm whether an account exists.
• Single-use tokens. Reset and activation links are random, stored only as a hash, time-boxed and consumed on first use.
• Rate limits on sign-in, recovery and two-factor resend.
• Anti-phishing recovery. A user must pick their real company from decoys before any reset is sent.