Skip to main content
Servicing tracks each loan account individually. The portfolio surface reads the book in aggregate, so you can see the shape of the and which loans are falling behind without querying loan by loan. Both reads answer from a snapshot of one business day, never from a live scan of the book. That is what makes them cheap enough to put on a dashboard, and it is also why they answer for a date rather than for “now”.

Portfolio dashboard


GET /api/v1/dashboard/portfolio returns the aggregate picture of the active book for a business date: outstanding, current and delinquent exposure, the count of active and delinquent loans, disbursement and repayment volume, and the portfolio-at-risk ratios at 30, 60 and 90 days. Alongside them it returns the loan count and exposure per delinquency bucket, a month-by-month trend leading up to the date, and the drill-down rows for the bucket you asked about. Narrow the read with productIds and productVersionIds. Omit asOf and Lender uses the current business day in Brazil.

Delinquent loans


GET /api/v1/dashboard/delinquent-loans returns the register behind the numbers: the loan accounts sitting in one delinquency bucket, page by page, so you can prioritise collections and provisioning. Ask for a bucket with bucketCodecurrent, 1_30, 31_60, 61_90, 91_plus, or the cumulative par30, par60 and par90 — and narrow to one loan officer’s book with assignedOfficerId. Brazil has an alias, GET /api/v1/br/dashboard/delinquent-loans, that adds a filter on the regulatory carteira C1 to C5 of Res. BCB 352/2023 to every filter above: the business date, the products, the product versions, the bucket, the loan officer and the paging all still apply. The carteira is derived from the product, so one that no product declares returns an empty page.

Where the numbers come from


A nightly snapshot job, off by default, measures every live loan account against the business day and writes the snapshot these two reads answer from. The PDD promotion sweep described in the Brazil regulatory pack depends on the same snapshot and builds it for its own business day when nothing else did, so a deployment that leaves the snapshot job off and keeps the sweep on still has a measured book.
A business date nobody measured is refused with 503, never answered with a page of zeros. An unmeasured book and a book with nothing overdue produce the same numbers, and answering the first as if it were the second would report a healthy portfolio that was never looked at. Treat the refusal as “retry”, not as “the book is empty”. The retry only starts answering once a producer has measured that date: the nightly PDD promotion sweep, which ships on, or the dedicated snapshot job, which ships off. With both of them off, no amount of retrying helps.
Each answer carries its own provenance: which snapshot it came from, the business date that snapshot measured, when it was generated, whether the freshness policy considers it stale, and why.

Audit is per-account


Portfolio views are aggregate reads; the authoritative, immutable record of what happened to any single loan is its GET /api/v1/loan-accounts/{id}/audit-events, covered in Service a loan. Every repayment, reversal, and replay lands there.

Next steps


Brazil regulatory pack

PDD staging, the nightly promotion sweep, and the provisioning the stages drive.