Digital Forms for Banks: Replacing Paper and PDFs Without a Portal
Ask a smaller bank how customers submit a PEP declaration and the answer is often a PDF or a paper form. Sometimes it's a fillable one, sometimes it isn't. Either way the customer has to download it and complete it, and then find a way to sign it and get it back, before someone internally reads it and keys it into another system.
Everyone agrees it should be digital, yet, what stops most banks is the assumption that going digital means building a customer portal: a proper self-service platform with its own onboarding flows, integrations and development roadmap. For a tier-one bank that's a reasonable investment but for a regional or mid-market bank will struggle to justify it for a handful of declarations and request forms.
So the PDFs stay, and the cost of keeping them builds up quietly.
What do paper-based forms actually cost?
Most of the cost doesn't show up on any budget line, it shows up in how the work gets done. Take a form that comes back incomplete for example, as someone has to chase it, and then match it to the original request once it returns, so a job that should take a day takes a week. Handwriting has to be interpreted and retyped, which is slow and introduces errors into records that regulators may later examine. Signed copies arrive by email, get saved to shared drives under whatever filename seemed sensible that morning, and are then hard to produce when an auditor asks for them.
The customer carries some of the cost too as being asked to print something in order to sign it has started to feel strange. For a bank that competes on service rather than scale, that impression matters more than it might for a larger one.
None of this is dramatic though and that's partly why it lasts because no single form feels worth a project, but together they add up to a lot of avoidable effort.
Is there a middle ground between PDFs and portals?
Jotform is a good example. It began as a straightforward online form builder and now it covers most of what a bank needs from customer data capture. Forms can adapt to earlier answers, so a customer only sees the questions that apply to them and signatures are captured inside the form. A visual workflow builder decides what happens after submission, and ready-made connections send the results to SharePoint, Google Drive, AWS S3 or anywhere else a bank will store their documents. Anything those connections don't cover can usually be reached through a REST API or a middleware platform that sits between systems.
What a bank ends up with feels like a portal from the customer's side, without the build that a portal implies.
Enterprise communications vendors have noticed the same gap and several now sell smart forms modules inside wider suites. They're capable products, but they arrive bundled with a platform decision many banks aren't ready or able to make, and a bank that only needs better forms doesn't need to buy a new suite to get them.
What does this look like in practice?
The PEP declaration is a useful example, because it's both ordinary and important. Banks have to identify customers who qualify as politically exposed persons and apply enhanced checks to their accounts and transactions - and none of that can start until the declaration has been collected.
We took an existing fillable PDF, lifted every field from it and rebuilt it as a Jotform form. Keeping the fields exactly as they were meant the wording compliance had already approved came across unchanged, so nothing had to go back through sign-off. The customer completes the form online, on a phone or a laptop, and signs it before submitting.
In some jurisdictions only a small number of e-signature providers are accepted by the regulator, so a signature captured just anywhere won't do. The perk of this solution allows for almost any e-signture provider to be used assuming they have a REST API. The customer doesn't notice any of this too, they fill in a form, sign it and move on.
After submission the workflow takes over and both versions go to the bank's archive, and the right team is notified. There's nothing to rekey and no attachment to hunt down in an inbox.
Which other forms follow the same pattern?
PEP declarations are one use among many. Most of the forms a bank handles regularly share the same basic shape: structured information from a customer, often a signature, and a record that has to end up somewhere dependable.
KYC and due diligence updates: Periodic reviews mean asking existing customers to confirm or update their details. A digital form makes that a short task for the customer, and it gives the bank a consistent, structured record instead of a pile of scanned pages.
GDPR and data subject requests: Requests often arrive by email in free text, which makes them easy to miss and hard to track against statutory deadlines. A dedicated form captures what's needed up front and starts the clock in a way that can be measured.
Complaints: A complaint that arrives complete, with the right details in the right fields, can be acknowledged and routed straight away. That makes a difference when regulators expect complaints to be handled within set timescales.
New product onboarding: Applications, supporting declarations and signatures can be gathered in one flow. The customer doesn't have to send documents in stages, and the bank doesn't have to assemble a file from several emails.
Each new form reuses the foundations laid by the last one. The integrations, storage rules and signing arrangements are already in place, so the second form is quicker than the first and the tenth is quicker still.
How should a bank get started?
The most useful first step is usually the least exciting one… list the forms you have. Most banks turn out to have more than they expected, spread across departments, with nobody quite sure who owns which version.
From that list, a few questions help decide where to begin:
Which forms come back incomplete most often?
Which ones carry a regulatory deadline or audit requirement?
Where do signed copies need to be stored, and for how long?
Does your regulator restrict which e-signature providers you can use?
The form that scores badly on most of these is usually a good first candidate and it's where the improvement will be most visible, and it'll show whether the approach suits your organisation before anything wider is committed.
Where does Holly Grove fit?
Holly Grove is now a Jotform partner. We build forms for the requests banks deal with most often, such as PEP declarations, KYC updates and complaints, and connect them to the archives, e-signature providers and core systems our clients already use. If it helps to see how that works before talking about your own forms, we're happy to walk you through a working example.
Jotform itself isn't difficult to use, and we wouldn't claim otherwise. The harder work sits around the form and it means knowing what a declaration needs to capture, where each record should live, and how the signing step satisfies local rules. It also means keeping twenty forms consistent once the first one has gone live. Many of the banks we speak to simply don't have a team they can spare for that, and they would rather have a finished outcome than another internal project.
For banks already running Lasernet, the same forms can feed directly into document generation and archiving in Lasernet Keep, which brings the input and output sides of customer communications together.
If you have forms still travelling on paper, by PDF or over email, we'd be glad to look at them with you. Send us one and we'll rebuild it as a working example, so you can see exactly what your customers would see before deciding on anything wider.