Building a client portal for a licensed financial firm: what the regulator expects behind the login

Photo by Daniil Komov on Pexels

What does client portal security for licensed financial firms actually involve? Mostly three things. The login. The session. The trail of who did what. A regulator can test each one, and a licensed firm can’t treat any of them as a nice-to-have. Teams that build the portal like a website tend to discover this late. What follows is a rundown of the rules and a build order.

Why a client portal counts as regulated ground

The portal is the front door. Clients walk through it to check a balance, pull a statement and sometimes send money. All of that sits inside the firm’s ICT risk framework, which in the EU means DORA. Applicants under MiCA are expected to document their ICT setup, vendors and outsourcing oversight next to governance and capital, a point laid out by Gofaizen & Sherle on crypto licence requirements.

Picture a supervisor’s first questions. How do users prove who they are? When does the session die? Could an admin edit last month’s logs? Each one maps to a written rule. “Best practice” language doesn’t survive contact with a license file, because a condition is something the firm has to evidence when asked. A control that exists only in a developer’s head isn’t evidence. Portal security is therefore a licensing question first and an engineering question second.

MFA behind the login: where rules get specific

Start with multi-factor authentication. New York’s 23 NYCRR 500.12, as amended, requires covered entities to apply MFA for any user on any information system, and the last phase took effect on 1 November 2025. Firms inside the regulation’s small-business exception have a narrower duty: MFA for remote network access, remote access to third-party applications, and privileged accounts other than service accounts. The rule names no method. Token-based MFA is the favored option in guidance, ahead of push prompts and texted codes. Biometrics come with a caveat: deepfakes can beat voice and video checks, and traditional fingerprints get the same caution, as Hogan Lovells notes in its summary of the amended Part 500. A CISO can sign off on an equally secure control, but it has to be reviewed at least annually. Access-control failures, MFA among them, were a focal point in five recent NYDFS settlements; a separate 2024 action against a cryptocurrency company concerned asset-inventory policies rather than access controls.

The EU takes a risk-based line. Article 21 of the DORA ICT risk-management standard asks for strong authentication on remote network access, privileged access, access to assets supporting critical or important functions, and anything publicly accessible. A client portal is publicly accessible by definition. Either way, it starts at the login screen.

Session management a regulator can audit

Sessions are where “secure enough” turns into a number. In the EU’s SCA rules, the number is five: a session that relies on strong authentication has to end after five minutes of inactivity. The scenario is easy to picture, a client stepping away from an open laptop in a café. There’s a carve-out. A client who only looks at balances or the payment transactions of the last 90 days can skip SCA, and the five-minute cap doesn’t bite for that read-only view. The renewal period used to be 90 days; Delegated Regulation 2022/2360 extended it to 180 days with effect from 25 July 2023, so a client can now go half a year between full authentications for that read-only access. The data limitation itself did not change. The EBA Q\&A most often cited on the five-minute rule dates from 2018, and the authority does not systematically revisit old answers when the law is amended — which is exactly how the 90-day figure survives in guidance that is no longer current.

Outside PSD2 nobody hands out a magic number. The firm picks one and writes down why. The usual building blocks:

• An idle timeout and a separate absolute session lifetime.
• Fresh authentication before sensitive actions, such as changing bank details.
• A visible list of active devices that clients can end.
• Automatic session revocation after a password reset.

What Belongs in the Activity Log

Logs are the evidence trail. Article 12 of DORA’s ICT risk standard lists what gets recorded. Identity and access control events. ICT operations. Change management. Network traffic. Retention is the firm’s call, based on risk. Tampering is the bigger worry, and the standard treats it that way: log data has to be protected against alteration, deletion and unauthorized reading. A failure in the logging system itself must be detected, and every clock should follow one documented time source. Clocks matter more than they sound. Let two servers drift four minutes apart and a breach timeline won’t add up. MiCA adds a longer view. Article 68 of Regulation (EU) 2023/1114 sets five years, extendable to up to seven where the competent authority asks before the five years elapse. When two retention periods clash, the longer one wins.

Who Else Can See Client Data

Clients aren’t the only users. Staff, support teams, contractors and APIs all touch client data. DORA’s access rules sound old-school, and that’s the point. Least privilege. Separated duties. Few shared accounts, and every user traceable to a person. Access gets reviewed once a year; for systems tied to critical or important functions, every six months. When someone leaves, or just stops needing access, it gets pulled without undue delay. The riskiest feature is often a support tool: the “view as client” button. If it exists, it needs its own log entry, an approval rule and an expiry date.

A pre-launch checklist for portal builders

Before launch, run these six checks:

1. Map every way in. Web, mobile app, API, support tools, admin consoles.
2. Put MFA on all of them, staff routes included.
3. Set idle and absolute timeouts, and write down why each value was chosen.
4. Send access events to a store that application admins can’t edit.
5. Take the longest retention period any applicable rule demands, and use it.
6. Schedule access reviews now, not after the first audit letter arrives.

Step four causes most arguments. Developers want logs in the database next to everything else; auditors want them somewhere a compromised admin account can’t reach. The auditors usually win. An outside vendor that builds the portal adds one more item to the file, since outsourcing oversight is part of what a license application documents. None of this is exotic. Good portal protection is mostly boring, fewer clever features and more evidence. That’s the whole of it in plainest form: proof, on request.

What licensed firms should build into version one

A portal can launch without a dark-mode toggle. It can’t launch without four things. First, MFA on every route, staff and support tools included. Second, session limits with documented values; 5 minutes idle is the number wherever PSD2 SCA applies. Third, logs that can’t be quietly edited, kept five years where MiCA record-keeping applies. Fourth, access reviews every six months for anything critical. Everything else can wait for version two. That short list is what a supervisor’s checklist actually covers.