Your data only goes where it is needed

A home loan application is one of the most personal files a person ever hands over. It holds a PAN, a date of birth, a phone number, an employer, an income, and a credit report that lists every loan and every late payment. At Nestara, that file passes through many hands: the customer, our calling team, relationship managers, builder partners, channel partners and lenders. Each of them needs some of it. Almost none of them need all of it.

We stopped asking "is our data safe?" and started asking a narrower question: for this person, on this screen, in this message, what is the least they need to see? Most of what we have built follows from that question.

Why this mattered

Leaks rarely come from a dramatic breach. They come from ordinary places: a screenshot of a CRM screen, a WhatsApp message forwarded to the wrong group, an export saved to a shared laptop, a partner account that can see more leads than it should. Every one of these is a small, legitimate action. None of them feels like a security event while it is happening.

So we can't rely on people being careful. The system has to make the careless version harmless. If a partner's screen never received the full PAN, then a screenshot of it leaks nothing.

The approach

Mask at the source, not on the screen

The easiest way to "hide" a field is in the UI: draw asterisks over it. We decided that doesn't count. If the full value is in the response, anyone with the browser's network tab has it.

For partner accounts on our CRM, masking happens on the server, before the response is built. A PAN reaches the partner as ABCDE****F. A date of birth arrives with only the year. A value that doesn't look like a valid PAN or date is hidden entirely, because a malformed value can be the real one, typed wrong. The rule applies everywhere the field appears: the applicant, every co-applicant, and the change history, which still records that a PAN changed, with both the old and new values masked.

Partners also can't edit those fields. That sounds like a product rule, but it is really a data integrity rule: if you can edit a masked field, you can save ABCDE****F over the real PAN.

If the full value never leaves the server, there is nothing to leak downstream.

A second lock on the CRM

Every connection to our platform runs over HTTPS. On the CRM, we add a second layer on top of it. Each API response is encrypted with AES-256-GCM before it leaves the server, using a key specific to the signed-in user, and that key rotates every week. The CRM decrypts the response in the user's own session.

That changes what an ordinary slip can expose. A response caught in a proxy log, a support screenshot of the network tab, or a browser extension reading traffic sees a sealed block, not a readable list of customers. GCM also carries an authentication tag, so a response altered on the way is rejected rather than shown. We treat this as a layer, not the wall: HTTPS, server-side masking and access scopes still do the heavy lifting.

Every partner sees only their own leads

Our mobile app is used by many channel partners (DSAs), often in the same city, sometimes competing for the same customers. One partner must never see another partner's leads, documents or credit reports.

Three rules make that hold:

• Identity comes from the session, never from the request. Each app request carries a signed token, and the server also checks it against its list of live sessions. A forged or ended session is refused before any data is read. The partner's identity is taken from that token. A partner ID typed into a request or a URL is never trusted on its own.
• Lists are filtered on the server. When a partner opens their leads, the database query itself is limited to that partner's leads. Nothing is fetched first and hidden afterwards.
• Teams are explicit. A partner can create or hand over leads only within their own reporting team. Anything outside it is refused.

When a partner leaves or is deactivated, the change is written to our audit trail, and their active leads move to our call-centre team so the customer isn't left waiting. The customer's file doesn't leave with the partner.

Scope every query in the CRM, too

The same idea applies to builder and partner accounts on the CRM. Every account resolves to an access scope when it logs in: the projects, journeys and partner channels it belongs to. That scope is applied to the database query itself, for lists, counts and exports alike, and checked again when a single lead is opened by its ID. A partner who guesses another lead's URL gets nothing, because the server asks "does this account have access to this lead?" every time, not only "is this account logged in?"

Treat messages as a data channel

Notifications are easy to forget. They feel like UX, not data. But a WhatsApp message to a salesperson is a copy of customer data that now lives on a personal phone, in a chat that can be forwarded.

When we audited our templates, we found two salesperson notifications that still carried the customer's full mobile number. They now show it masked, the same way our other templates already did: the last four digits, enough to match a call, and not enough to reuse. We checked every channel that could carry the number, not just the one in the ticket.

Don't pull data you won't use

Credit bureau pulls are both expensive and sensitive: each one fetches the customer's full credit history again. When a customer's Experian report already shows high risk, we now skip the extra CIBIL pull, because it couldn't change the outcome. That means one less full credit report fetched, stored and processed for a decision that was already made. Bureau pulls are also tied to the customer's consent record, so every report we hold can be traced back to the permission that allowed it.

Production stays behind its own door

Customer data lives in our production database, and that database is kept apart from everything else. Development and testing run against a separate environment with its own database, so building and testing a feature never touches a real customer's records. Access to production is limited to our own engineering team. It isn't open to partners or vendors, and no app or dashboard reaches it directly. Every request goes through the server and the checks above.

The way we work there is deliberately careful:

• No real bureau or identity calls on shared test environments. Testing never pulls a real person's credit report.
• Maintenance tasks on production connect to the database and nothing else. They don't start the rest of the application, so a data fix can't trigger a notification or a background job by accident.
• Every production data task runs as a dry run first, in small batches, and is reviewed before it writes anything.

Leave a trail people can trust

The sensitive actions in our CRM write an audit record: who did it, when, and what changed. That covers reassigning a lead's relationship manager, moving a lead to another partner, deactivating an account, correcting a customer's details, and re-running eligibility. An audit trail doesn't prevent a mistake, but it makes "who changed this?" a question with an answer, which makes misuse much harder to hide.

Every access rule is also written down. Our decision log records who can see what, why, and what we rejected. When someone later wonders whether a hidden field is a bug, the answer is already there.

The result and what we learned

None of this is one big feature. It is many small decisions that point the same way: send less, show less, keep less, and record what happens to the rest. The lesson we keep relearning is that security work is mostly an inventory problem. The hard part isn't masking a PAN. It's finding every place a PAN travels: the response, the history, the export, the notification, the edit form.

Where this is heading

The direction we're moving in is to make "least data" the default rather than a rule we apply field by field. We want sensitive fields to be labelled as sensitive where they are defined, so every new screen, export or message inherits masking instead of needing someone to remember it. We want access to be granted for a purpose and for a time: a relationship manager sees a customer's full details while working the lead, not forever. And as more of our credit analysis runs automatically, we want those systems to work on the minimum facts they need, such as a risk level or a payment pattern, rather than on raw identity documents.

The goal is a system where a leak needs several things to go wrong at once, and where the data someone could take is already the least useful version of it.

Frequently asked questions

Is my data safe on Nestara?

Your data travels over encrypted connections, is stored in a production database only our engineering team can access, and is shown to each person only as far as their role needs. Partners see masked identity details, only their own leads, and every sensitive change is logged. No system can promise zero risk, but ours is built so that a single mistake doesn't expose your file.

Who can see my PAN and date of birth?

Our internal team, which works your application, sees them in full. Builder and channel partners see a masked PAN (for example ABCDE****F) and only the year of your birth. The full values are never sent to their screens, and partners cannot edit them.

Can another agent or partner see my application?

No. Each partner's app and CRM account only returns the leads that belong to them or their own team. The check runs on our server for every request, so changing a link or an ID doesn't reveal anyone else's file.

Is my credit report pulled without my permission?

No. Every credit bureau pull is tied to the consent you gave, and we skip pulls that wouldn't change the outcome of your application.

Who at Nestara can access the production database?

Only our engineering team. Partners, vendors and apps never connect to it directly. Development and testing use a separate environment, so they never touch real customer data.

What happens to my file if my agent leaves?

Their account is deactivated, and the change is recorded. Your application moves to our call-centre team, so it keeps moving, and the agent no longer has access to it.

Why do I see only the last four digits of a phone number in messages?

The messages we send to our salespeople mask customer numbers, for example ******3210. That is enough to match a call, and not enough to misuse the number if the message is forwarded.