The refund destination field: higher education's cheapest theft
Somewhere in your student information system is a field that redirects a five-figure disbursement. It sits in the same profile screen as the preferred-name setting, governed by the same permission, protected by the same password.
Which student record field is worth the most to an attacker?
The refund destination. A student information system treats address, phone and bank details as one class of profile data, but only one of them causes money to move. Tiering by consequence rather than by record type is the cheapest change available.
- Student information systems model banking details as profile attributes because self-service was introduced to reduce bursar workload. No consequence tiering was applied.
- The student bears the debt even when the disbursement was stolen, which makes this unusually harsh compared with consumer payment fraud.
- Tier the fields by dollar value at risk; in most systems fewer than five fields carry nearly all of it.
Part of Education and credential identity
A Tuesday in the bursar's office
The student came in during the second week of the spring term because her rent payment had bounced. Her aid had disbursed on schedule. The refund had gone out on schedule. To an account she had never seen.
Her portal password had been in a credential-stuffing list since a breach at an unrelated service two years earlier. Someone logged in, changed one field, and waited. The portal sent a change notification to her student email address, which she checked roughly weekly, and which by then was also compromised.
The institution's position was that the change was made from her account. Her position was that she did not make it. Both were true. She still owed the loan.
Why the field ended up in the profile screen
Self-service refund enrolment was a genuine improvement. Before it, students queued at the bursar's office with a voided cheque, and staff keyed the details. Moving it online reduced queues, errors and staffing cost.
The modelling decision followed the interface. Banking details went where other student-supplied details go: the profile. Nothing in that decision considered that one of these fields moves money and the others do not.
Tiering the student record
Run this against your own SIS. List every field a student can change, and rank by the dollar value a wrongful change can move or destroy.
| Tier | Value at risk | Fields | Authorisation warranted |
|---|---|---|---|
| T1 | Full disbursement value | Refund destination, direct deposit details | Student-held credential, full detail rendered, notification with delay |
| T2 | Moderate financial or academic | Enrolment changes affecting aid, withdrawal, payment plan setup | Student-held credential |
| T3 | Privacy | Directory information disclosure, FERPA release settings | Session, with notification |
| T4 | None | Preferred name, notification preferences, theme | Session |
The exercise usually produces one or two T1 fields, which is precisely why it is affordable. Nobody is proposing a credential gesture for changing a preferred pronoun.
The notification problem
Institutions rely on change notification as a compensating control, and it is better than nothing. Its weakness in this specific fraud is that the notification channel — the student email address — is frequently compromised in the same credential-stuffing event.
If notification is part of the design, send it to every enrolled authenticator and to a channel the student controls independently, and build in a delay so a notification that arrives has time to be acted on.
What this costs an institution with thin IT staffing
Be realistic. A regional public institution with four people in IT is not deploying an identity platform. The work that matters:
- Identify the T1 fields. An afternoon.
- Add a credential requirement at that one change point. A scoped integration, not a platform.
- Enrol students at an existing touchpoint — orientation, first aid counselling, first portal login of the term.
- Fund the assisted path in the bursar's office, which already exists physically.
- Measure diversion reports and re-issuance before and after.
Why institutions make students whole anyway
Many do, and the reason is not generosity. A student whose aid was stolen cannot pay tuition, will likely withdraw, and the institution loses the enrolment, the retention metric and the goodwill — while the federal debt follows the student regardless.
That means the loss is frequently absorbed by the institution in practice even where policy says otherwise. Which makes prevention a straightforward cost comparison rather than a moral argument.
A consequence tier model for a student record
| Tier | Fields | Gate |
|---|---|---|
| Cosmetic | Preferred name, communication preferences | Session |
| Contact | Address, phone, emergency contact | Session plus notification |
| Access | Credential enrolment and recovery | Bound assertion |
| Payment | Refund destination, deposit details | Bound assertion plus a hold |
Objections and honest limits
“Students will not tolerate friction.” They will tolerate it once, on the field that pays them, and they already tolerate more friction than this to reset a password.
“Our SIS does not support per-field authorisation.” Most do not natively. The gate can sit in front of the endpoint rather than inside the product, which is a smaller change than a vendor request.
Tiering an existing student record
- List fields by what changing them causes. Not by which screen they live on.
- Find the payment-consequential set. Usually three or four fields.
- Put a bound assertion in front of those endpoints. In front of the SIS if it cannot do it natively.
- Notify out of band and hold the first payment. Two cheap additions that close the timeline.
Terms used here
- Consequence tiering
- Assigning authorisation strength by what a change causes rather than by which record it belongs to.
- Student information system
- The system of record for enrolment, academic and financial data.
- Out-of-band notification
- A message through a channel the changing session cannot reach.
Frequently asked questions
Is the student really liable for a stolen disbursement? The federal loan obligation attaches to the borrower. Institutional practice on making students whole varies, and many institutions do so for enrolment and retention reasons even where not required.
Would MFA on the portal solve this? It helps considerably and is worth deploying. It does not address a session compromised after login, and it applies the same strength to every field rather than to the one that moves money.
What about students who change banks mid-term? That is the normal case the control must handle smoothly — a credential gesture and a notification delay, not a trip to the bursar.
How do we enrol students who never come to campus? Remote enrolment at first portal login, with an assisted telephone path. Fully online programmes need this designed deliberately rather than inherited from the on-campus flow.
Why tier by consequence rather than record type? Because a single record contains fields whose misuse ranges from cosmetic to a direct payment redirect.
How many fields are payment-consequential? Usually three or four — refund destination, deposit details, third-party payer authorisation and withholding elections.
What if the SIS cannot gate per field? Put the gate in front of the endpoint. It is a smaller change than a vendor feature request.
Where this fits in Manav
Manav binds the authorising person to the exact record or disbursement being authorised, and produces a receipt an auditor, a regulator or a receiving institution can verify without contacting the issuer.