Data Handling Requirements for Financial Services Websites

Most financial websites are built as though data handling will take care of itself. The form posts, the partner integration redirects and comes back, the analytics tag fires, and everyone moves on to the next feature. A year later there is a spreadsheet of customer details on someone’s laptop, a chat tool that has been quietly recording support conversations, and a retention policy written by somebody who has never opened the database. By then the interesting decision — what to collect at all — has been made by accident, usually by whichever feature demo ran last.

The real requirement in a regulated business is not secrecy. Most engineering teams can already keep secrets. It is knowability: being able to say where every field came from, why it is held, who can open it, when it is deleted, and what happens when a customer asks you for it or asks you to delete it. That has to be designed, because retrofitting it onto a live system with real records in it is expensive and unpleasant.

What follows is the version of that conversation we usually have with clients in financial services, in roughly the order it happens.

Start with a data map, not a page design

Before anyone opens a design tool, we produce a table. One row per field, with columns for where it arrives from, why it is needed, whether we store it or only forward it, who inside the business should see it, where it ends up afterwards, and how long it should live. It is an unglamorous artefact and it takes longer than sketching a homepage. It also prevents most of the expensive late surprises. At SmartEdge IT Solutions this is usually the first thing we produce for a regulated build, and it is often the only document that anybody reopens a year later.

For a regulated client that map usually produces three lists: data we store ourselves, data that transits our servers on its way somewhere else, and data a third party collects whether we invited it or not. Only the first is fully in your gift, which is a decent reason to spend the most attention on it and to be sceptical about the other two.

Then we delete fields. This is the step teams resist, because every field in a demo looked reasonable. Do you need a date of birth if nothing is calculated from age? Do you need a full address if the relationship is digital and post is never involved? Do you need a scanned identity document for an account that does not move money? Often the honest answer is no, and removing a field removes a category of problem permanently rather than temporarily.

Holding data and passing it through are different obligations

A redirect to a partner’s application form looks like an outbound link. In practice you may be handling personal data at the moment the customer submits it, and that distinction changes your contracts, your record-keeping and what your privacy notice has to claim.

We tend to shape these flows so data moves directly from the browser to the destination wherever the destination will accept it. Fewer copies means fewer places to leak data from, and fewer places to forget about when a subject access request arrives. Where a direct post is not possible — some onboarding journeys insist on a server-side handoff — we make the transit explicit: the payload is passed through, logged in redacted form, and never written to a table on our side.

Language about bank-grade security deserves scepticism in any proposal. Ask which specific controls are being claimed, by whom, and with what evidence. “Bank-grade encryption” is not a control. TLS in transit with a current cipher configuration, encryption at rest on the storage volume, and secrets held in a managed store instead of a config file are three things you can be shown. Our server hardening work exists largely to answer that sort of question with something more concrete than an adjective.

Consent has to live in the interface

A cookie banner is the most visible part of this and the least important. What matters is whether the interface makes it possible to say no and still use the thing. If refusing marketing storage leaves the enquiry form broken, the consent is not real, and no rewrite of the wording fixes that.

In practice that means the necessary and the optional get separated in the markup rather than only in the label. Analytics and tag scripts stay unloaded until accepted. Preference storage is readable and editable by the person it belongs to. The panel does not shift the layout when it appears, and it does not trap focus on a small screen.

Two things get settled in writing early. First, which category each vendor falls into — some advertising and personalisation vendors genuinely cannot operate without storage, and pretending otherwise produces a consent rate that collapses later when somebody audits it properly. Second, how long a consent lasts before you ask again. Twelve months is a common working assumption; shorter is defensible and many businesses prefer it. Either is fine. Having no stated rule is not.

Audit the scripts, not just the server

Server-side controls matter, and they are the part most teams actually review. The part most teams skip is everything injected after page load. A tag manager is a convenient way for marketing to add and move tags without a deployment, which is exactly why it is also a way for a third-party script to appear on a page that contains an application form.

Before launch we inventory what genuinely loads: every analytics property, every advertising tag, every chat tool, every personalisation widget. Then three questions per script. Does it fire on pages where personal data is displayed? Does it capture form input, even partially? Can consent state block it, or is it hard-coded in a template where the tag manager cannot reach it?

The uncomfortable finding here is usually that capture is unintentional. A support tool with session replay switched on will cheerfully record a customer typing a password into a help form. Disabling replay on form pages is a small change with a disproportionate effect, and it is exactly the sort of thing we look for during a full website audit, because it is invisible until somebody opens the network panel.

Retention is a product decision, not a storage setting

Retention gets discussed as a database job. It behaves more like a product decision, because somebody has to choose the periods and those choices carry business consequences. How long do you keep a rejected application? A closed account? A complaint record? A support transcript? Marketing contact history?

The pattern we push for is a rule per field rather than a rule per table. Some fields are needed for the life of the relationship. Some are needed for a defined window after it ends, because a dispute can surface years later. Some should never have been stored at all. Writing it per field is tedious, and it produces a much shorter list of awkward questions than one global “delete after N months” setting ever will.

Deletion then becomes testable. If we can run a query that finds records past their retention date and return a count, retention is a mechanism. If deleting means remembering to remember, it is a policy document. Where a backup schedule conflicts with a deletion obligation, we write that conflict into the risk register plainly rather than hoping nobody asks — backups have their own expiry, and that conversation belongs in writing before it turns urgent.

Access, logging, and being able to prove who looked

Regulated staff do open customer records; that is the job. The control is not preventing access, it is bounding it and recording it. Two mechanisms do most of the work. Role-based permissions, so a support agent cannot read a credit file by default. And audit logging on reads of sensitive records, not only on writes, because the question somebody eventually asks is who looked, not who changed.

Read logging carries a cost in volume, storage and the discipline of actually reviewing it, so we scope it to the records that warrant it rather than switching it on everywhere. That is a deliberate trade and we would rather agree it with you than impose it. What we will not do is leave it out and then describe the system as auditable.

The same logic applies to the people who support the platform. Production access should be attributable, time-limited and requested rather than standing. That is as much cloud infrastructure management as access control, because the storage question and the permissions question get answered together or not at all.

The requests that always arrive late

Subject access, rectification and deletion requests come from people who have no idea how your system is arranged and who are often irritated by being asked to prove who they are. The replies that go badly are the ones where no export was ever possible and someone had to reconstruct one by hand during the fortnight.

The preparation is unglamorous. A single defined route for requests, monitored rather than left in one inbox. A way to confirm identity without demanding documents nobody is required to supply. An export that runs across your actual stores — the primary database, object storage, the ticketing queue, the third-party tool you forgot about — in a format a person can read. And a written note of what cannot be produced, because search indexes, derived analytics and support transcripts each fail differently and nobody should be discovering that during an incident.

None of this is visible on the website. It is also the difference between a business that answers a regulator calmly and one that spends a fortnight in a shared document trying to work out what it holds.

What we usually advise clients to leave out

Every regulated project gains scope through good intentions. A document upload “just for verification” that turns into the largest storage and retention problem in the system. A free valuation widget that quietly needs an email address and starts a marketing relationship from a regulated page. A conversational assistant trained on internal material that begins answering questions it ought to refuse.

Where AI features are in scope they need the same discipline as anything else. An assistant on a financial site will be asked for things it should not answer, so the safe design constrains it: approved content only, an explicit refusal path, no free-text storage beyond a defined window, and a route to a person. We treat AI chatbot development for a regulated client as a data-handling project first and a model project second, because that is the ordering which survives a difficult question later.

The build is the straightforward part. The requirement is really a set of decisions about data, made explicitly and written down, so that when the business changes shape next year the answers are still findable. If a client’s compliance team wants to review those decisions before build rather than after, that is a better project, and SmartEdge IT Solutions has no objection to it.