Building Customer-Facing Portals for Financial Institutions: What Actually Works

Over the last few years, our team at Speqto Technologies has built portals for NBFCs, cooperative banks, insurance brokers, and a couple of wealth management firms. One thing that keeps surprising clients: the hardest part is rarely the UI. It’s getting core banking integrations, compliance workflows, and support escalation to work together without the whole thing collapsing under its own complexity. This post is a walkthrough of what we’ve learned, including a few mistakes we’d rather not repeat.

Start with the core system integration, not the design

We worked with a mid-sized NBFC in Pune that wanted a loan servicing portal — customers checking EMI schedules, downloading statements, raising prepayment requests. The client came to us with Figma mockups already done. We had to push back and start over on the backend first.

Why? Their core lending system (a Finnone instance) only exposed batch-processed data refreshed twice a day. The mockups assumed real-time balance updates. We ended up building a sync layer with Redis caching and a webhook listener for same-day transaction updates, with a visible “last updated at” timestamp on every balance screen so customers weren’t confused by lag. That one UI decision — just being honest about data freshness — cut support calls about “wrong balance” by close to 40% in the first two months.

Lesson: map your core banking/insurance/AMC system’s actual data latency before anyone touches a wireframe.

Authentication is not a checkbox, it’s a trust signal

For a cooperative bank client, we implemented a multi-factor setup combining OTP, device fingerprinting, and a soft lock after failed attempts — but we deliberately avoided CAPTCHA puzzles that frustrate older customers, a big chunk of their user base. Instead we used invisible risk scoring (based on IP reputation and login velocity) and only triggered a hard challenge when something looked off.

For a fintech lending app we built, we used OTP-less login via registered device + PIN for returning users, reserving full OTP flow only for new device logins. This dropped login drop-off from roughly 22% to 9%, based on their analytics post-launch.

The point isn’t which method you pick — it’s that financial portals need tiered authentication, not a single rigid flow applied to every user equally.

Compliance has to be architecture, not an afterthought

With RBI’s data localization rules, SEBI’s cybersecurity framework for intermediaries, and now the DPDP Act adding consent-management obligations, we design these in from day one rather than bolting them on before launch (which is what happens with a lot of portals built by generalist dev shops).

• Data residency: all PII and transaction data for our BFSI clients sits on servers physically in India, with DR instances also within country borders.
• Consent logging: every time a customer shares a document or grants data access (say, for a loan application pulled via Account Aggregator), we log the consent artifact with timestamp and purpose, retrievable for audits.
• Audit trails: admin actions — refunds processed, KYC overrides, account freezes — are logged immutably. For an insurance broker client, this became critical during an IRDAI audit; they pulled six months of logs in under ten minutes instead of the two days it used to take manually.

Document-heavy workflows need their own UX thinking

KYC re-verification, loan document uploads, claim submissions — these are where most financial portals lose users. For an insurance claims portal we built, the original flow asked customers to upload 7 documents in one go. Completion rate was under 50%.

We broke it into a progressive flow: upload one document, get instant OCR-based validation feedback (wrong format, blurry scan, mismatched name), then move to the next. Completion rate went up to around 78%. The OCR layer used Google Document AI for structured documents like Aadhaar and PAN, with a fallback manual review queue for anything confidence-scored below 85%.

Don’t underestimate the support handoff

A portal that can’t gracefully hand off to a human is a liability in BFSI. For a wealth management client, we built a “request callback” button embedded directly in transaction history screens — so if a customer is confused about a specific SIP deduction, they can tap that exact line item and it auto-populates a support ticket with the transaction ID, date, and amount. Their support team told us ticket resolution time dropped by almost a third because agents weren’t spending the first five minutes just figuring out what the customer meant.

What we’d tell any BFSI decision-maker starting this project

• Audit your core system’s API/data capabilities before committing to a UX timeline.
• Treat authentication as a spectrum, not a single gate.
• Build compliance logging into the database schema, not as a reporting layer added later.
• Test document workflows with actual low-bandwidth, older-device users — not just office wifi and new phones.
• Make human handoff a designed feature, not a fallback.

Portals for financial institutions aren’t really “websites with login” — they’re thin layers sitting on top of genuinely complex, regulated systems. The projects that go well are the ones where engineering, compliance, and support teams are in the room together from week one, not brought in sequentially. That’s been true across every BFSI engagement we’ve run at Speqto, regardless of institution size.