The credit reporting and risk registry shared by TmpTech and its member lending institutions across the Kingdom of Tonga.
TmpTech Credit Bureau gives Bureau staff and member banks a single, shared record of who owes what, to whom, and how reliably it's being repaid. It's built around one identifier that never changes across institutions: a person or business's National ID.
Every account a member institution reports becomes a Trade Line linked to one Credit Subject — so a customer's repayment history follows them between banks, not just within one. A Credit Score and Risk Rating are calculated from that shared history and refresh automatically whenever a Trade Line changes. Every time a lender checks someone's history, that check itself becomes a permanent Bureau Enquiry, logged against the subject's recorded consent.
Register individuals and businesses once, by National ID, and never duplicate them again — the system finds and reuses an existing record automatically.
Member institutions report accounts — loans, overdrafts, credit cards — with balances, delinquency status, and payment history.
Every credit check is logged, timestamped, scored, and tied to a consent reference.
Fraud flags, delinquency triggers, and disputes surface automatically and route to Bureau staff for resolution.
Member institutions are billed per enquiry and by subscription tier; fee runs post straight to accounting.
What a user can see and do is controlled per page and per record type — editable by a Bureau Administrator, no code change required.
Bureau Administrators and Officers running the registry day to day, and Member Institution staff submitting trade lines and enquiries for their own bank. Where a step is administrator-only, the page says so.
Regulatory context. The bureau operates under National Reserve Bank of Tonga (NRBT) licensing as a credit information provider — most visibly in the consent requirement covered in Credit Subjects, and in NRBT's own read-only oversight access covered in Security & Compliance. Tonga does not yet have a dedicated data protection statute; see the public Privacy Policy for how the bureau handles that gap.
Five roles cover everyone who signs into the Bureau Portal. What each one sees is a combination of its Frappe role and, for member banks, which institution it belongs to.
| Role | Typically | Data scope |
|---|---|---|
| Bureau Administrator | TmpTech bureau management | Everything, bureau-wide — plus the only role that can change page and permission configuration. |
| Bureau Officer | Bureau analysts | Everything, bureau-wide, except administration screens. |
| Member Institution | Bank / lender staff | Only their own institution's submissions and enquiries. |
| Member Institution Admin | One designated staffer per bank | Same as Member Institution, plus managing that bank's own portal users on My Team. |
| Credit Regulator | NRBT oversight staff | Read-only, bureau-wide, and only on Member Lenders, Alerts & Disputes, and Reports — no write access anywhere, and no access to the Credit Subject / Trade Line / Bureau Enquiry registry itself. See Security & Compliance. |
A member user's institution is resolved from a Frappe User Permission record, not from anything the user can edit — so a bank can never see another bank's data by changing a filter.
Every item in the sidebar is gated by a Page Permission record mapping its route to the roles allowed to open it:
| Page | route | Allowed roles |
|---|---|---|
| Dashboard | dashboard | Bureau Administrator, Bureau Officer |
| Subject Registry | subjects | Bureau Administrator, Bureau Officer, Member Institution, Member Institution Admin |
| Credit Enquiries | enquiries | Bureau Administrator, Bureau Officer, Member Institution, Member Institution Admin |
| Trade Lines | trades | Bureau Administrator, Bureau Officer, Member Institution, Member Institution Admin |
| Member Lenders | members | Bureau Administrator, Bureau Officer, Credit Regulator |
| Bureau Fees | fees | Bureau Administrator, Bureau Officer |
| Alerts & Disputes | alerts | Bureau Administrator, Bureau Officer, Credit Regulator |
| Reports | reports | Bureau Administrator, Bureau Officer, Member Institution, Member Institution Admin, Credit Regulator |
| My Billing | billing | Member Institution, Member Institution Admin |
| My Team | team | Member Institution Admin only |
This table is data, not code — a Bureau Administrator can change any row of it from the Desk. See Page Permissions.
The Bureau Portal is one page with a fixed sidebar. Everything below is one click from anywhere.
A page a role isn't allowed to open simply doesn't appear in its sidebar — there's nothing to discover by URL either, since the same rule is enforced on the server for every request the page makes.
A Credit Subject is one individual or one business — the person or entity every Trade Line, Enquiry, and Alert is ultimately about.
Every Credit Subject has a required, unique National ID (an individual's government-issued NID, or a business's registration number). It's the one thing that identifies a customer the same way at every member institution, and the system leans on it hard:
Consent is mandatory. A Credit Subject cannot be saved without Data Sharing Consent Given checked and dated.
| Status | Meaning |
|---|---|
| Active | Normal, reportable subject. |
| Deceased | Confirmed deceased — retained for record, not for new reporting. |
| Emmigrated | Confirmed to have left Tonga. |
| Suppressed | Excluded from search results and bureau reporting. |
| Fraud Watch | Flagged for suspected identity fraud — pushes Risk Rating to Very High. |
| Bankrupt | Under bankruptcy — also pushes Risk Rating to Very High. |
| Dissolved | Business subjects only: the entity no longer exists. |
Both are calculated automatically by the scoring engine — bureau staff never set them by hand. The score recalculates whenever a linked Trade Line changes, and lands in one of six bands:
| Band | Score range |
|---|---|
| Excellent | 750 – 850 |
| Very Good | 700 – 749 |
| Good | 650 – 699 |
| Fair | 550 – 649 |
| Poor | 450 – 549 |
| Very Poor | 300 – 449 |
Risk Rating (Low / Medium / High / Very High / Declined) follows the same score, overridden to Very High whenever the fraud flag is set or the subject is on Fraud Watch or Bankrupt. For what actually moves the number and how to explain a change, see Understanding Credit Scores.
What the number on a Credit Subject's record actually measures, what moves it, and how to answer a member institution — or a subject — who asks why it changed.
Every Credit Subject carries a TCB-Score on a 300–850 scale, calculated by the bureau's scoring engine — never entered by hand. It's recalculated automatically, stored alongside a score_band and a separately-computed risk_rating, and every recalculation is written to that subject's score history.
Very Poor Poor Fair Good Very Good Excellent — see the full range table on Credit Subjects. A brand-new subject with no reportable history yet shows No Score rather than a number.
The score is built entirely from a subject's own Trade Line portfolio — the same aggregates shown on their profile:
Running a Bureau Enquiry on a subject never affects their score — enquiries are logged for the record, but only Trade Line activity feeds the scoring engine.
These are two different things computed from the same record, and it's easy to conflate them:
| Risk Rating | When it applies |
|---|---|
| Low | Score of 700 or higher. |
| Medium | Score of 620–699. |
| High | Score of 500–619. |
| Very High | Score below 500 — or the subject has the fraud flag set, or Registry Status is Fraud Watch or Bankrupt, regardless of score. |
That last row is the one to remember: flagging a subject for fraud pushes their Risk Rating to Very High immediately, but it does not rewrite their numeric TCB-Score — the two stay independently readable, on purpose.
Every change — automatic or manual — is appended to that subject's score history with the previous score, the size of the change, what triggered it, and any notes. If a member institution asks why a score moved, that history is where the answer lives.
No. A Bureau Enquiry is only ever logged against the subject — it has no effect on the scoring engine.
Open their profile and check the score history: the most recent entry's trigger event and score change explain it — almost always a Trade Line moving into delinquency or its utilization increasing.
Yes, for corrections — but it's logged exactly like an automatic recalculation, so there's always a record of who changed it and why.
They haven't got any reportable Trade Line history yet. The band fills in once a member institution reports their first account.
A Trade Line is one credit account — a loan, credit card, or overdraft — belonging to one Credit Subject and reported by one Member Institution.
Every Trade Line carries the reporting institution, the subject's name and National ID, credit limit, current balance, and utilization — all visible without opening the linked Credit Subject.
Delinquency status runs from current to charged off, and drives both the subject's Risk Rating and any automatic Credit Alert:
Current 30 Days 60 Days 90 Days 120 Days 150 Days 180+ Days Charge-Off
A Trade Line also keeps a running count of times it's been 30, 60, and 90 days past due, and a record of the worst status it's ever reached — so a since-recovered account still shows its history.
Each Trade Line's detail view shows its month-by-month payment record. Flag, on that same detail view, opens a dispute — you're required to give a reason before it submits, which is recorded against the account. Flagging doesn't remove the Trade Line from the registry; it marks it disputed (the detail view then shows Disputed instead of Flag, so it can't be flagged twice while the dispute is open) and raises a Credit Alert so the dispute lands in the Alerts & Disputes queue for review.
Only the institution that reported a Trade Line — or Bureau staff — can flag it; another institution can't dispute an account it doesn't own.
Every time a member institution checks a customer's credit history, that check is logged as a Bureau Enquiry — permanently.
An enquiry captures who ran it, which subject it was about, the subject's score at that exact moment, and why the check was made:
| Enquiry purpose |
|---|
| Mortgage · Home Loan · Personal Loan · Auto Loan · Business Loan · Overdraft · Credit Card · Consumer Finance · Agriculture Loan · Education Loan · Micro Finance · Employment Check · Tenancy Check · Other |
Each enquiry also records a consent reference — evidence the subject agreed to the check — and resolves to a result: Pending Approved Declined Referred Cancelled.
Because the score is snapshotted at enquiry time, an enquiry record still shows exactly what the lender saw, even after the subject's score has since moved.
Both Credit Subject and Requesting Institution are search-as-you-type fields — search by name, National ID, or institution name rather than entering an ID from memory. For a Member Institution user, Requesting Institution is filled in and locked to their own institution automatically; only Bureau staff can search across institutions.
Alerts are how the bureau surfaces things that need a human look — some raised automatically by the system, others logged by staff.
| Alert type | Typical trigger |
|---|---|
| Fraud | Suspected identity fraud on a subject. |
| Delinquency | A Trade Line crosses a delinquency threshold. |
| Dispute | A subject or institution disputes a reported account. |
| Enquiry | Unusual enquiry activity on a subject. |
| Data Quality | Something in the registry looks wrong or incomplete. |
| System · Compliance · Other | Everything else worth flagging. |
Each alert also carries a severity — High Medium Low Info — so the queue can be worked in order.
Status moves through Open → Acknowledged → Resolved, or Dismissed if it turns out not to need action. A Dispute-type alert is raised automatically whenever a Trade Line is flagged — see Trade Lines.
The directory of banks and lenders participating in the bureau — every Trade Line and Enquiry belongs to one of these.
A new member record needs its institution name, primary contact, phone, email, and headquarters (island group). Two capabilities are set independently, since not every member does both:
A Rate Limit and Daily Limit cap how much an institution can submit or enquire in a given window, and a membership tier (for example Gold, or no tier at all) determines its billing plan — see Bureau Fees & Billing.
A new member starts as Pending Approval and moves to Active once approved, with a start date and — where the arrangement is time-bound — an expiry date. The Member Lenders list also shows each institution's last submission and last enquiry, so a bureau officer can spot a member that's gone quiet.
Approving a member automatically links it to a billing customer, so its first invoice doesn't need any manual setup.
Rotate Key, on an Active member's detail panel, immediately invalidates that institution's current API key and generates a new one — you're asked to confirm first, since any integration still using the old key starts failing authentication the moment you do. The new key is shown exactly once, in a copyable box; the server only ever stores a hash of it, so if it's lost, the only way to recover is to rotate again.
Where a Member Institution Admin manages their own bank's Bureau Portal users — visible only to that role.
These controls only ever touch users already tied to your own institution — the server checks the institution on every request, so My Team can't be used to reach another bank's team even by a mistyped ID.
New accounts are provisioned by the bureau administrator, not by self-service invitation from My Team.
How member institutions are charged for using the bureau, and where each side of that goes to review it.
Every member institution subscribes to one of three tiers via a Bureau Plan. The tier sets the annual membership fee and the per-unit rate for the two metered fee categories — Enquiry and Submission both bill per unit with no free allowance, so cost tracks usage directly:
| Fee | Platinum | Gold | Silver |
|---|---|---|---|
| Annual Membership Fee (billed annually) | T$5,000.00 | T$3,500.00 | T$1,500.00 |
| Enquiry Fee (per enquiry) | T$2.50 | T$3.00 | T$5.00 |
| Submission Fee (per trade line submitted) | T$1.25 | T$1.50 | T$2.50 |
A one-time Setup Fee of T$1,500.00 applies at onboarding, the same for every tier. This same schedule is published on the public site's Pricing section.
Invoices land as Draft by default (Submit Invoices is unchecked) so they can be reviewed before they post to the ledger as a real receivable.
| Page | Who sees it | Shows |
|---|---|---|
| Bureau Fees | Bureau Administrator, Bureau Officer | The fee ledger and billing runs across every member institution. |
| My Billing | Member Institution, Member Institution Admin | Only that institution's own subscription, entitlements, and invoices. |
An institution's outstanding balance shown on My Billing is always derived live from its own submitted Sales Invoices — never a stored counter that could drift out of sync with what's actually been posted.
The Dashboard is the bureau's at-a-glance view; Reports is the standing catalog for anything that needs to be pulled on demand.
Summarizes the registry bureau-wide: subjects by score band, open Credit Alerts by severity, and recent Trade Line and Enquiry volume — the same six score bands used throughout the guide (Excellent through Very Poor), so the picture here matches every subject's own profile.
Bureau-wide, for Bureau Administrator, Bureau Officer, and Credit Regulator (NRBT oversight):
| Report | Category | Status |
|---|---|---|
| Monthly Bureau Statistics | Statistical | Ready |
| New Subject Registrations | Registry | Ready |
| Delinquency Portfolio Report | Risk | Ready |
| Top Debtors by Outstanding Balance | Risk | Ready |
| Fraud Alert Summary | Compliance | Ready |
| Member Lender Activity | Member | Ready |
| Score Migration Analysis | Risk | Pending |
| FATF Compliance Report | Compliance | Pending |
Own-institution only, for Member Institution and Member Institution Admin:
| Report |
|---|
| My Institution Portfolio Summary |
| My Enquiry Activity Report |
| My Delinquency Report |
| Data Submission Compliance |
A Ready report's Download button generates and streams a CSV of live data on the spot — there's nothing pre-built or cached sitting behind it. A Pending report isn't built yet; its Generate button is a placeholder.
The doctype that decides which roles can open which page — editable from the Desk, with no code change or deploy.
Each Page Permission record maps one route (the sidebar page it corresponds to — trades, billing, and so on) to a list of roles allowed to open it. The rule is simple:
The change takes effect immediately — every user's next page load re-fetches the current permission table.
This is a UX convenience as much as a security control: the same rule is enforced again on every server request that page makes, so hiding a sidebar link is never the only thing standing between a role and the data.
Page Permission controls which pages a role can open. Two more things, both also Bureau Administrator-editable, control what a role can do once it's there:
Both are read live by the portal on every sign-in — nothing about who can do what is hardcoded in the interface.
What actually stands between a role and data it shouldn't see, and where that's rooted in Tongan credit bureau regulation.
National ID isn't just a field on Credit Subject — it's the identifier the whole registry is matched on. It's required and unique at registration, it's what bulk submissions from member institutions are matched against before a new subject is ever created, and it's carried onto every Trade Line, Bureau Enquiry, and Credit Alert so a record can be traced to a real customer without a second lookup. If a National ID is ever corrected on a Credit Subject, that correction cascades automatically to every linked record — nothing is left showing a stale value.
A Credit Subject cannot be registered without recorded consent, and every Bureau Enquiry carries its own consent reference. Neither is optional or backdatable from the portal.
A member institution's staff see only their own institution's data. This is enforced with Frappe's own User Permission records — not a filter the frontend applies, so it can't be bypassed by calling the API directly. Bureau Administrators and Officers see across every institution.
The Credit Regulator role gives National Reserve Bank of Tonga staff read-only access to Member Lenders, Alerts & Disputes, and Reports — enough to supervise the bureau's conduct without the open-ended ability to browse the underlying consumer credit registry. It has no doctype permission on Credit Subject, Trade Line, or Bureau Enquiry at all, and no write, create, or delete permission anywhere. Reports it can pull are the same bounded CSV exports covered in Reports & Dashboard, not direct database access.
Every action the portal exposes is checked on the server, independently of whether the page that calls it was visible in the sidebar:
Because both checks run on the server, nothing about what's shown or hidden in the interface is ever the only thing protecting a record.