industries · banking & financial services

Access reviews and MFA coverage that an examiner can test line by line.

A bank's core, card, lending and wealth platforms often come from different decades, each with its own idea of access. Examiners still want MFA everywhere, privileged access under control and leavers removed on time. We build the controls, and the evidence that shows them working.

industry / banking-financial-services 4 rules in scope
01 · USERS 02 · ACCESS CONTROLS 03 · BANKING SYSTEMS 04 · EVIDENCE Employees and contractors: branch · operations · IT Employees andcontractors branch · operations ·IT Third parties: service providers · fintechs Third parties service providers ·fintechs Workforce SSO and MFA: Okta · Ping · Entra ID Workforce SSO andMFA Okta · Ping · Entra ID IGA and SoD rules: certifications · toxic combos IGA and SoD rules certifications · toxiccombos Privileged access: core admins · DBAs · vendors Privileged access core admins · DBAs ·vendors Core banking: deposits · loans · GL Core banking deposits ·loans · GL Card and payments: PCI cardholder data environment Card andpayments PCI cardholderdataenvironment CRM: Salesforce CRM Salesforce Customer data platform: masking · row policies Customer dataplatform masking · rowpolicies Exam and audit evidence: FFIEC · NYDFS · PCI DSS Exam and auditevidence FFIEC · NYDFS · PCIDSS
SailPointSaviyntCyberArkOkta
in short·20-second read

Banks and other financial firms have to show examiners who can reach customer data, that MFA covers every user and that access is reviewed and removed on time.

Cohash implements identity governance, privileged access and workforce MFA across core banking, card and CRM systems. We also build governed data access in Snowflake or Databricks and map the controls to FFIEC guidance, NYDFS Part 500, the GLBA Safeguards Rule and PCI DSS 4.0.1.

you probably need this if
  • The NYDFS MFA inventory shows a list of apps marked compensating control with no annual review.
  • Core banking access is granted by emailing the vendor, and nobody keeps the reply.
  • Loan officers can approve loans they originated. The SoD rule exists, but only in a policy document, where no system enforces it.
Ask an engineer facts checked 2026-10-20 · 8 sources
how it runs
  1. 01Map each rule to its systems
  2. 02Measure who can reach regulated data
  3. 03Fix and automate the controls
  4. 04Produce evidence auditors can sample
rules
FFIEC Authentication and Access GuidanceNYDFS Cybersecurity RegulationGLBA Safeguards RulePCI DSS v4.0.1
from rule to evidence

How a regulation turns into proof.

For banking & financial services, each rule below lands as a control, the control runs on a platform, and the platform leaves a record an auditor can read.

  1. 01

    Rules you answer to

  2. 02

    Controls we build

    Identity governance with separation of dutiesMFA coverage mapping and rolloutPrivileged access for core and cloudIdentity consolidation after acquisitionsGoverned customer data
  3. 03

    Platforms that enforce them

  4. 04

    Evidence your auditors read

    Access review records Joiner, mover and leaver logs Privileged session records Change and approval history Control-to-rule mapping
the story · banking & financial services access program

From the first call to a setup your own team can run.

Here's what usually prompts a call about your banking & financial services access program, what we do about it and in which order, and where you end up.

  1. chapter 01 · where it hurts

    Why teams reach out

    • The NYDFS MFA inventory shows a list of apps marked compensating control with no annual review.
    • Core banking access is granted by emailing the vendor, and nobody keeps the reply.
    • Loan officers can approve loans they originated. The SoD rule exists, but only in a policy document, where no system enforces it.
  2. chapter 02 · what we change

    How we solve it

    • Identity governance with separation of duties
    • MFA coverage mapping and rollout
    • Privileged access for core and cloud
    • Identity consolidation after acquisitions
    • Governed customer data
  3. chapter 03 · how it runs

    Our approach

    • Map each rule to the systems it touches
    • Measure who can reach regulated data today
    • Fix access and automate the controls
    • Produce evidence auditors can sample
  4. chapter 04 · where you end up

    What changes

    • The compensating-control list shrinks to the few that need it, each with a dated annual review.
    • One review now covers both banks.
challenges and answers

Where it usually goes wrong, and what we do about it

where it goes wrong
  1. 01

    Core platforms with their own access models

    Core banking, card processing and loan origination each keep roles their own way, and some only through a vendor-hosted admin console. Getting them under one governance process takes connector work. It also takes people agreeing on what each role actually means.

  2. 02

    MFA gaps on legacy applications

    NYDFS now expects MFA for every user on every information system. Older internal apps, terminal emulators and vendor portals that can't do SAML or OIDC are where coverage usually breaks.

  3. 03

    Privileged access to core and payments

    DBAs, core administrators and vendor support staff hold standing access to the systems that move money. Session recording and just-in-time elevation are often missing on the oldest of them.

  4. 04

    Acquired institutions bring their own directories

    Each acquisition adds another Active Directory, another core and another set of access reviews. Until they're merged, examiners see two control environments.

  5. 05

    Customer data copied into analytics

    Account and transaction data ends up in warehouses and model sandboxes with full identifiers attached. Every copy needs to be in the access review, and in the GLBA or Part 500 risk assessment.

how we help
  1. 01

    Identity governance with separation of duties

    Certification campaigns and toxic-combination rules for lending, payments, treasury and general ledger roles. The rules check a request before access is granted. Campaigns are sized so reviewers can actually finish them.

  2. 02

    MFA coverage mapping and rollout

    An inventory of every application and access path with its MFA status, then federation, proxies or compensating controls for the hard cases, documented the way NYDFS and examiners ask for.

  3. 03

    Privileged access for core and cloud

    Vaulted credentials, recorded sessions and time-bound elevation for core administrators, DBAs and vendor support. We do this on CyberArk, BeyondTrust or Delinea, and the CDE is in scope.

  4. 04

    Identity consolidation after acquisitions

    Directory and IGA migration for acquired institutions, with role mapping agreed before the cutover so access doesn't double up on day one.

  5. 05

    Governed customer data

    Masking, row access policies and role hierarchies in Snowflake or Databricks so analysts and models see the minimum customer data they need, with grants driven from governance.

typical situations

Situations we walk into

We pieced these together from banking & financial services situations that come up a lot. They're patterns. You won't find a specific client in them.

case file 01

A Part 500 MFA inventory with forty compensating controls

composite · not a client story
  1. Beforethe situation

    A bank licensed in New York has forty internal applications sitting under compensating controls in its MFA inventory. Most were approved in a hurry before November 2025. The CISO signed them, and that was the last time anyone looked.

  2. What we dothe work

    We test each listed app for SAML or OIDC support and put web apps that can't federate behind an access proxy. Thick clients move behind a jump host with MFA. What's left goes back to the CISO with a written rationale and a review date.

  3. Afterwhere you end up

    The compensating-control list shrinks to the few that need it, each with a dated annual review. The MFA inventory matches what an examiner would find by testing.

case file 02

Two cores, two forests and two review calendars after an acquisition

composite · not a client story
  1. Beforethe situation

    Post-acquisition, the combined bank is running two core platforms and two Active Directory forests. It also runs two certification programs, on different schedules. To an examiner that's two control environments, and the acquired bank's loan officers hold roles nobody has mapped.

  2. What we dothe work

    First we map roles in the acquired core to the acquiring bank's role model, with the business owners in the room. Next the acquired core and directory are onboarded into the existing IGA platform. Then one certification cycle runs across both institutions, before core conversion.

  3. Afterwhere you end up

    One review now covers both banks. Role meanings were agreed before conversion, so separation-of-duties rules hit loan officers on both sides the same way.

architecture

Where identity controls sit between bank staff and core systems

Staff and third parties sign in through workforce SSO with MFA. Governance provisions and reviews their access to each banking system, and privileged sessions go through a vault. Review results and session logs feed exam and audit evidence.

Where identity controls sit between bank staff and core systems Staff and third parties sign in through workforce SSO with MFA. Governance provisions and reviews their access to each banking system, and privileged sessions go through a vault. Review results and session logs feed exam and audit evidence. 01 · USERS 02 · ACCESS CONTROLS 03 · BANKING SYSTEMS 04 · EVIDENCE sign-in federation provision provision role grants MFA into CDE recorded session review results session logs Employees andcontractors branch · operations · IT Third parties service providers ·fintechs Workforce SSO andMFA Okta · Ping · EntraID SP IGA and SoD rules certifications ·toxic combos CA Privileged access core admins · DBAs ·vendors Core banking deposits · loans · GL Card and payments PCI cardholder dataenvironment Sf CRM Salesforce Customer dataplatform masking · rowpolicies Exam and audit evidence FFIEC · NYDFS · PCI DSS
Read the diagram as text
  1. Employees and contractors → Workforce SSO and MFA: sign-in
  2. Third parties → Workforce SSO and MFA: federation
  3. IGA and SoD rules → Core banking: provision
  4. IGA and SoD rules → CRM: provision
  5. IGA and SoD rules → Customer data platform: role grants
  6. Workforce SSO and MFA → Card and payments: MFA into CDE
  7. Privileged access → Core banking: recorded session
  8. IGA and SoD rules → Exam and audit evidence: review results
  9. Privileged access → Exam and audit evidence: session logs
case studies

Work on the platforms banking & financial services runs on

All case studies
talent and delivery · banking & financial services

Certified engineers, wherever you need them.

Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
01Does the GLBA Safeguards Rule apply to banks?

It comes down to who regulates you. If you're a mortgage broker, payday lender or fintech, you're probably a non-bank financial institution, and the FTC's Safeguards Rule is yours. Banks and credit unions follow their own regulators' interagency safeguards guidelines under GLBA. They ask for much the same things. We map controls to the one that applies.

02Can you connect governance to our core banking platform?

Usually, through whatever the core provider supports, whether directory groups, flat-file feeds or APIs. Where a core only accepts changes through its admin console or a vendor ticket, we build ticketed fulfillment with tracked completion so the evidence is still there.

03How do we get MFA onto applications that don't support SAML or OIDC?

It depends on the application. Options include an access proxy or gateway in front of web apps, MFA at a privileged access jump host for thick clients, and documented compensating controls the CISO approves in writing for the few that are left, which Part 500 permits with annual review.

04How long does an IGA rollout take at a bank?

It depends mostly on how many applications need connectors and how clean HR and directory data are. We size it after a short discovery that counts both, rather than quoting before we have seen your estate.

05Do you work with our core banking vendor or around them?

With them, using whatever interfaces they support. Some cores will only take a change by ticket. We still track each of those requests to completion, because that's where the evidence comes from. And we only work in vendor systems you've given us access to.

services

Services for banking & financial services

The services banking & financial services clients ask us for most, alongside the work on this page.

next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it