An LO wanted a spreadsheet. Nothing sinister — she was building her own referral tracker, so she hit Export on the pipeline screen and opened the CSV at her desk.
It came down with the whole branch in it. Every file, every LO, the two deals the sales manager was quietly working, and a margin column that has never once appeared on her screen. She turned the laptop around because she thought the file was broken.
Nothing was broken. The screen was doing exactly what it was built to do — draw the rows that belong to her seat. The export was talking to a different door, and nobody had ever told that door about seats.
The short version
- Two locks, and most branches only bought one: what a seat can read, and what a person can move once they've read it.
- Ask every vendor where the "no" lives — the screen, or the database. A hidden tab is a promise; a row-level rule is a lock the export inherits.
- The two losses that actually happen in a branch — the diverted wire and the departing LO's exported book — are move problems. No permission setting stops either.
- Say the wire sentence out loud at application, before the attacker gets a turn. Verify every change on a number you already had.
- Kill access in the first hour, from a written list, starting with the session and not the password.
A hidden button is a promise. A row-level rule is a lock.
There are two ways an app can keep an LO out of the branch financials.
The wrong way: the server hands over everything and the app declines to draw it. The P&L tab doesn't render for that seat, and everyone feels covered. But the data still traveled. Anyone with developer tools open, anyone calling the API with their own valid login, anyone who clicks Export — same pot. The lock is painted on.
The right way: the database refuses. That's row-level security with the jargon stripped out. Every row carries a rule about who may read or change it, and the database checks that rule on every request — not on every screen, on every request. A report, an export, a scheduled email, an API call, a bug shipped last Tuesday, a feature nobody has written yet: they all inherit the same no.
A hidden button is a promise that every screen and every future release will remember. A database rule is a lock that doesn't care what anyone remembered.
It's the standard we built MAVYN to: financials render only for owner and sales-manager seats, and access is enforced at the database row level.
The seat map, and the question that draws it
Role-based access is a plain idea with an ugly name — every seat gets what the job requires and nothing else. The concept isn't the hard part. Almost nobody has written the map down.
Draw it on one page before you shop, and fill it in with the phishing test: assume this seat's password is in a stranger's hands tonight — what did you just lose? Not "do I trust this person." Blast radius. Your best LO of ten years doesn't need the branch P&L to close loans, so it shouldn't be one click from her seat. That's not an insult. It's what caps the damage the night a laptop walks out of a closing.
Federal safeguards rules already put this duty on a mortgage shop. The standard worth holding is simpler: if the borrower read over your shoulder, would they be comfortable with who in the office can open their file?
The second lock nobody buys: what a seat can move
Permissions govern reading. They go silent the instant somebody looks at something they were entitled to look at — and that's where the real losses live, because the person is authorized.
Two moves cause nearly all of it.
- The forward. A full 1003, a driver's license, two months of bank statements, pushed to a personal inbox to work on at home. Now the file's most sensitive document lives in a mailbox with no policy, no logging, and a password from 2019.
- The export. A departing LO's whole book, in a CSV, three weeks before the resignation letter. Every branch that has lost a producer has thought about this afterward.
Neither is a permission failure. Both are process:
- Name one system of record and forbid working from copies. Every spreadsheet on a desktop is a branch you can't revoke.
- Make export an event, not a silent button — logged, attributed, visible to a manager.
- Move documents through a portal. If a borrower can't send a paystub without attaching it to an email, you built the leak yourself.
The wire window, and the sentence that closes it
Here's the mechanism most people miss. The wire attack doesn't require breaking into your software. It requires one compromised inbox anywhere in the transaction — the borrower's, the agent's, the title company's, an assistant's — and patience. The attacker reads the thread and waits. When it starts saying clear to close and we're funding Thursday, the "updated wiring instructions" arrive from a lookalike domain, in the voice of somebody the borrower already trusts.
Four inboxes touch a closing. You control one.
The defense isn't encryption. It's two sentences said at fixed moments. The first goes at application, before anything else:
"One rule before we go further: I will never email you wire instructions, and neither will the title company. If you get an email with wiring instructions, or a change to instructions — even if it looks exactly like mine — it's fraud. Before you move a dollar, call the number on their website, not the number in that email, and read the account back to a human."
The second is internal, with no exceptions: any change to wire instructions is verified on a number you had on file before the request arrived. Not the signature block. Not a reply to the thread.
The first hour after a seat goes away
Terminations are when access rot surfaces. Order matters more than speed.
- End the session, not just the password. A password change doesn't log anyone out. Kill sessions and revoke tokens, or the phone in their pocket stays signed in all afternoon.
- Reassign ownership before you disable. Pipeline, leads, tasks, files in process. Orphaned loans are how a borrower ends up calling a dead extension the week of closing.
- Walk the whole tool list — LOS, pricing engine, credit vendor, e-sign, document portal, CRM, shared mailbox. Any one of them holds client PII.
- Rotate anything shared. A shared login is the account nobody disables, because nobody owns it.
- Read the last thirty days of exports. Not to build a case. To know what's out there.
- Tell the lock desk. Locks in that name still have expirations, extensions, and a cost when they blow.
Run it from a written list. The version you improvise is the one that leaves the pricing engine open for a year.
An AI that reads everything will repeat anything
AI makes this sharper, not softer. An assistant that composes your morning or watches files for stalls has to read broadly to be useful. But breadth of reading is breadth of repeating — not out of malice, out of helpfulness.
The rule: the assistant answers as the seat that's asking. Same rows, same limits. When a vendor demos an AI feature, ask it plainly — "when my processor asks about the branch, what data does it read from?" If the answer is "everything, but it's smart about what it shares," that's a hidden button with better manners.
Six questions, and how to hear the answers
- Where does enforcement live — in the application, or in the database?
- If one of my LOs calls your API with their own valid login, what comes back?
- Can you show me the access rule itself, not the screen that hides the data?
- Who at your company can read my branch's data, and is that access logged?
- What exactly happens in the first hour after I terminate a seat?
- Do your AI features inherit the permissions of the person asking?
Good answers are boring and specific: row-level policies in the database, the API returns only their rows, here's the audit log. Bad answers are warm and vague: we take security very seriously, that's never come up, the interface doesn't show that. The interface was never the question.
What to do Monday
Three moves, no budget. List every seat and every system holding client data, and what each login can see today. Get a test login at the LO level and go hunting for what that seat shouldn't find — check the reports and the exports, not just the tabs. Then kill stale access: the LO who left, the processor before her, last summer's intern.
Notice how long the system list gets. Every extra tool holding client data is another set of doors, another place a former employee may still have a key — a security argument stacked on the operational one for running the branch from one source of truth.
Your clients handed you the most sensitive file of their lives. The least the software can do is lock it, instead of tucking it behind a tab.