Getting structured loan data out of a Shellpoint-serviced mortgage account

A Shellpoint login opens onto one mortgage loan at a time: current balance, next payment due, escrow status, a running activity log, downloadable statements and the year's Form 1098. The same servicing platform sits behind a row of sponsor-branded sites — GMFS, FirstBank, Achieve, Logan Finance, Second Act, Change Home Mortgage — so the data shape is consistent even when the front door says someone else's name. Shellpoint Mortgage Servicing is the third-party servicing brand of Newrez LLC, whose servicing arm was reported to have rebranded as Rithm Servicing in early 2024 under Rithm Capital Corp. The integration question here is not whether the data exists. It does, per account. It is which authorized route gets it out cleanly and keeps it flowing.

Bottom line: this is a rich authenticated portal, not a thin one. A serviced mortgage carries amortization state, escrow math driven by tax and insurance bills, payment scheduling, and tax artifacts — all addressable per loan once a consenting account holder is in session. The route we would actually build on is authorized protocol analysis of that session, because it returns every field the borrower can see at full fidelity; a consented aggregation feed sits alongside it for the standardized liability fields. We arrange the account access and the working agreement with you as part of the engagement.

Loan record contents

Each row below is a surface a logged-in borrower actually reaches in the Shellpoint app or web account, mapped to what an integrator does with it.

Authorized ways in

Three routes genuinely apply to a Shellpoint-serviced account. They differ in fidelity, durability, and what we stand up to run them.

1. Authorized protocol analysis of the account session

With the account holder's authorization, we analyze the traffic the Shellpoint app and myaccount web client exchange with the servicing backend, then reimplement the calls behind a clean interface. Reach: everything the borrower can see — full loan snapshot, payment history, escrow analysis fields, document lists, 1098. This is the highest-fidelity route and the one we would build the spine on. Durability is good but tied to the portal surface; effort is moderate. We set up the consented test account or sponsor environment with you during onboarding.

2. User-consented aggregation feed

A US liabilities-aggregation rail (the kind documented by Plaid's Liabilities product) can return standardized mortgage fields — loan number, original amount, interest rate, property address, escrow balance, last payment date — once the borrower consents, refreshed roughly daily. Reach is narrower than route 1 and the field set is fixed by the aggregator, but it is durable and low-maintenance. We use it as a secondary, normalized feed rather than the primary.

3. Consented credential access with native document export

Where the need is the paperwork itself, a consented session pulls the native downloads the portal already offers — e-Statements, escrow statements, the yearly 1098 — as files, with the structured fields parsed out on top. Lowest effort, narrowest scope; useful as a document-vault fallback or alongside route 1.

For most asks we make route 1 the backbone and let route 2 cover the normalized liability fields where a borrower prefers an aggregation consent. Which mix fits depends on whether you need every borrower-visible field or just the standardized ones; we settle that in the first scoping call.

Statement pull, sketched

Illustrative only — field names and the auth chain are confirmed against a consenting account during the build, not asserted here. It shows the shape: a session token from the login exchange, a loan context, then a statement-and-escrow read with the sponsor host parameterized.

POST /auth/session            # myaccount.shellpointmtg.com (or sponsor host)
  body: { username: <email>, secret: <...>, deviceCtx }
  -> 200 { sessionToken, mfaState }

GET  /loans                    # loans visible to this borrower
  hdr:  Authorization: Bearer <sessionToken>
  -> 200 [ { loanId, sponsorBrand, status } ]

GET  /loans/{loanId}/snapshot
  -> 200 { principalBalance, nextDueDate, escrowStatus,
           interestRate, lastPaymentAmount }

GET  /loans/{loanId}/escrow/analysis?year=2026
  -> 200 { paymentBreakdown:{ principalInterest, escrow },
           projection:[ ... ], history:[ ... ] }

GET  /loans/{loanId}/documents?type=1098&taxYear=2025
  -> 200 { docId, available:true, format:"pdf" }

# error handling we wrap:
#   401 -> re-run session exchange, replay once
#   423 -> MFA / step-up challenge surfaced to the consent flow
#   404 on taxYear -> 1098 not yet posted for that year; do not treat as failure

What lands in your repo

Deliverables are tied to the surfaces above, not a generic checklist:

• An OpenAPI/Swagger specification covering the session exchange, loan list, snapshot, payment activity, escrow analysis and document/1098 endpoints as implemented for Shellpoint.
• A protocol and auth-flow report: the token chain, MFA/step-up behavior, session lifetime, and how the sponsor-branded hosts share one backend.
• Runnable source for the key reads in Python and Node.js, with the sponsor host as a parameter so one client serves every branded portal.
• Automated tests against a consenting account or sponsor environment, including the year-rollover and not-yet-posted-1098 cases.
• A normalized schema that lines up the protocol fields with the aggregation feed, so route 1 and route 2 return the same shapes.
• Interface documentation plus data-retention and consent-logging guidance written for mortgage-servicing data specifically.

US data-rights footing

There is no single US account-aggregation mandate that cleanly forces a mortgage servicer to publish a borrower-data feed. The CFPB's Section 1033 Personal Financial Data Rights rule was finalized in October 2024, but a federal court has enjoined the CFPB from enforcing it and the Bureau reopened the rule for reconsideration through a 2025 advance notice; whether and how mortgage servicers sit inside its scope is exactly one of the unsettled points. Because that footing is in flux, we do not build on its specific compliance calendar, and we do not state those dates as binding obligations here. The route instead rests on authorized, account-holder-consented access: the borrower authorizes the integration, consent scope is recorded, the consent can be revoked, and the data set is minimized to what the use case needs. We operate authorized and documented — access logged, consent records kept, NDA in place where the engagement calls for one. That posture holds whichever way Section 1033 is finally written.

What we plan around

Specifics of this app that shape the build, handled on our side:

• One backend, many brands. GMFS, FirstBank, Achieve, Logan Finance, Second Act and Change Home Mortgage are sponsor-branded servicing sites on the same Shellpoint platform. We map the shared surface once and parameterize the host, so a loan on any branded portal resolves through a single client rather than a separate integration per brand.
• Two different clocks. Payment activity moves daily while the escrow analysis re-runs only about once a year. We split the sync so the slow escrow re-analysis and the fast payment polling run on their own cadences and neither hides the other.
• The 1098 is a once-a-year, tax-year-keyed artifact. We build the year rollover and the electronic-1098 opt-in notification into the pull, so a request near year boundaries fetches the correct tax year and treats a not-yet-posted form as pending, not as an error.
• The delivery surface moves; the data does not. A portal redesign shifts fields without changing what a serviced loan contains. We version the integration against the observed surface and ship a re-validation suite so a front-end change is a quick re-map, not a rebuild.

How it is priced

Two ways to engage. You can take source-code delivery: runnable code, the OpenAPI spec, tests and interface docs land in your repo, from $300, and you pay after delivery once you are satisfied with what arrived. Or you can use the hosted API and pay per call, with no upfront fee — you call our endpoints and pay only for what you use. A typical Shellpoint build runs one to two weeks. You bring the app name and what you want from the loan data; access, the consenting account or sponsor environment, and any paperwork are arranged with you as part of the work. Send the requirement through our contact page to scope it.

Integrations people ask for

Two end-to-end asks that come up for a serviced mortgage:

• Escrow-shortage early warning. Poll the snapshot and escrow analysis, detect when the projection implies a payment increase, and push the borrower a heads-up before the annual escrow letter arrives — driven by route 1 fields.
• Year-end tax export. On a schedule, fetch the posted Form 1098 plus the December statement for every serviced loan a consenting user holds, parse the interest figures, and hand a bookkeeping system both the numbers and the source PDFs.

App screens

The screens we worked from, taken from the public store listing.

What was checked

This mapping draws on the Shellpoint online-account walkthrough and FAQ on shellpointmtg.com (dashboard layout, Payments/Statements/Mortgage Assistance tabs, 1098 access, escrow analysis), public reporting on the Newrez/Rithm Servicing relationship, and the documented behavior of a US liabilities-aggregation API for the secondary feed; the Section 1033 status reflects the CFPB and Federal Register record as of mid-May 2026. Primary sources opened:

• Shellpoint — step-by-step guide to the online account
• Shellpoint — escrow analysis
• Plaid — Liabilities API documentation
• CFPB — Personal Financial Data Rights reconsideration

Mapped and written by the OpenBanking Studio integration desk — reviewed 2026-05-16.

Other servicers

Same category, useful when one integration has to cover loans across servicers. Named for ecosystem context only.

• Mr. Cooper — large non-bank servicer; borrower app with loan, payment and escrow detail.
• Rocket Mortgage — servicing and origination in one account, with self-service payment and document access.
• PennyMac — servicing portal carrying balance, payment history and statements per loan.
• Freedom Mortgage — servicer with online payment, escrow and document surfaces.
• LoanCare — subservicer powering many lender-branded portals over a shared backend.
• Select Portfolio Servicing — special and primary servicer with an account portal for payments and documents.
• Dovenmuehle Mortgage — subservicer behind numerous bank and credit-union mortgage front ends.
• RoundPoint Mortgage Servicing — servicing portal with loan snapshot and payment management.
• Selene Finance — servicer and special servicer with online account access to loan and escrow data.

Integrator questions

My loan shows up under a sponsor brand like GMFS or FirstBank — does that change the integration?

No. GMFS, FirstBank, Achieve, Logan Finance, Second Act and Change Home Mortgage are sponsor-branded front ends that resolve to the same Shellpoint servicing platform behind the scenes. We map the shared servicing surface once and treat the branded host as a parameter, so a loan on any of those portals is handled by one client without a separate build per brand.

Can the escrow analysis and the yearly 1098 come back as structured data, not just PDFs?

Yes. The escrow analysis carries a payment breakdown, escrow projection and escrow history, and the Form 1098 carries fixed box values for interest and related amounts. We extract those into typed fields and still keep the original PDF as an attached artifact for record-keeping, so you get both the parsed numbers and the source document.

Does the CFPB open-banking rule force Shellpoint to expose this data through a standard feed?

Not in a way you can rely on today. The CFPB's Section 1033 Personal Financial Data Rights rule was finalized in October 2024, but a federal court has enjoined the CFPB from enforcing it and the Bureau reopened the rule for reconsideration in 2025, with how mortgage servicers are covered still unsettled. Our route does not depend on that rule landing; it uses authorized protocol work and user-consented aggregation that work regardless of where Section 1033 ends up.

If Shellpoint redesigns the myaccount portal, does the integration stop working?

A front-end redesign can move fields, so we version the integration against the observed surface, ship a small re-validation suite with it, and offer a maintenance pass that re-maps the affected calls when the portal changes. The data domains themselves — loan snapshot, payments, escrow, statements, 1098 — are stable; it is the delivery surface that moves, and that is the part we keep watch on.