AI and IT consulting for regulated financial institutions.

AI governance in a bank, broker-dealer, or insurer is fundamentally a model-risk-management problem with new failure modes layered on top of the SR 11-7 framework that the OCC and Federal Reserve already expect. The work begins with a use-case taxonomy that maps each model to its consequence tier, its regulatory exposure under the EU AI Act Annex III high-risk categories where applicable, and the validation depth required by the institution's own MRM policy. From there, a senior consultant produces decision records for each in-scope model: training-data lineage, fairness and disparate-impact testing methodology, adversarial robustness evidence, drift-monitoring thresholds, and the human-in-the-loop arrangement that owns the override path. The NIST AI RMF supplies the control vocabulary; the institution's existing MRM artifacts supply the format examiners already accept. Successful outcomes look like a model-risk committee that can approve or deny new AI use cases on a defined cadence, validation packages a regulator reads without follow-up, and a deployment pipeline where governance gates are technical controls rather than meeting cycles. An engagement typically runs eight to twelve weeks, embedded with model risk, the AI center of excellence, and one or two business-line model owners, with a week-one inventory and gap assessment, a mid-engagement governance design, and a final cutover that includes one production model migrated end-to-end through the new control set as proof.

Core banking modernization is the work of moving deposits, loans, payments, and the general ledger off a thirty-year-old COBOL or AS/400 platform without a six-month service interruption or a regulator finding. The strangler-fig pattern is the dominant approach: route new product traffic to a modern core, keep the legacy core authoritative for in-flight portfolios, and reconcile both ledgers daily until the legacy state is fully drained. A senior consultant produces a domain decomposition of the current core, a parallel-run reconciliation harness with tolerance bands defined per account class, a cutover playbook keyed to FFIEC examination expectations, and a regulator-facing change-management package that documents the operational-resilience implications under the OCC heightened-standards framework. Successful outcomes are measured by clean parallel-run reconciliations across a full month-end and quarter-end, an auditor who signs off on the dual-ledger period, and a customer-facing experience that is unchanged through cutover. The hardest decisions are not technical: they are the operational tradeoffs a CIO has to make when the cutover window is twelve weeks instead of twelve months, and a senior consultant earns their place by surfacing those tradeoffs early, in writing, with regulator implications attached. An engagement typically runs twelve to twenty weeks for the program-design phase, embedded with the core program team, treasury operations, and the chief risk officer.

An FFIEC-aligned cloud landing zone is a cloud foundation engineered so that an examiner under the FFIEC IT Examination Handbook can trace a control from policy to evidence without an internal scavenger hunt. The work begins with the institution's existing risk taxonomy, the cloud provider's shared-responsibility model, and a control mapping to the FFIEC handbook, the OCC heightened-standards expectations, and where applicable the NYDFS 500 cybersecurity rule. A senior consultant produces account-hierarchy and organizational-unit design, network segmentation patterns aligned to data-classification tiers, key-management posture under FFIEC and NIST SP 800-57 guidance, and a logging-and-monitoring architecture that produces immutable audit evidence for both privileged-access activity and configuration drift. The deliverables are landing-zone-as-code (Terraform or CloudFormation), a control-evidence catalog mapped to examination procedures, and runbooks for the operational tasks examiners ask about most often: customer-data segregation, encryption-key custody, third-party access, and incident response. Successful outcomes look like an examination cycle that closes without a Matter Requiring Attention on cloud governance and a posture that survives a change in cloud provider region, account, or business line without redesign. An engagement typically runs eight to twelve weeks, embedded with cloud platform engineering, information security, and the regulatory examination liaison, with a week-one current-state assessment and a final pilot account stood up under the new posture.

Data lineage in a regulated institution is not a documentation exercise; it is the substrate that lets a model-risk team, a finance team, or a compliance team answer the question "where did this number come from" inside the timebox a regulator allows. The work starts with the institution's authoritative-source-of-record inventory, BCBS 239 risk-data-aggregation principles, and the specific reporting obligations in scope (FR Y-9C, CCAR, FR 2052a, MiFID II transaction reporting, or the institution's own model-risk evidentiary needs). A senior consultant produces a data-contract catalog between source systems and consuming platforms, a lineage-tooling selection grounded in the institution's existing platform footprint rather than a vendor demo, and the lakehouse instrumentation that captures column-level lineage as code rather than as a periodically refreshed diagram. Deliverables include a data-product taxonomy, lineage automation in the orchestration layer, control evidence that maps a feature in a production model back to its source extract, and a remediation backlog for orphaned or non-conforming pipelines. Successful outcomes look like an examiner question answered with a query rather than a forty-hour internal investigation, and a model-risk team that can re-run a feature derivation against a prior point-in-time state. An engagement typically runs ten to fourteen weeks, embedded with the chief data office, model risk, and the platform engineering team that owns the lakehouse.

Operational resilience under the EU's Digital Operational Resilience Act, the Bank of England's SS1/21, and the corresponding US interagency expectations is a discipline of identifying important business services, defining impact tolerances, and proving through testing that the institution can stay within those tolerances under severe-but-plausible disruption. The work begins with an important-business-service mapping, dependency analysis across applications, third parties, people, and facilities, and impact-tolerance setting in the language the regulator expects. A senior consultant produces the resilience instrumentation that DORA Article 28 actually requires: third-party ICT register entries with the contractual provisions DORA mandates, scenario-based tabletop and severe-but-plausible exercise plans, RTO and RPO documentation grounded in measured recovery rather than aspirational targets, and the post-exercise remediation discipline that turns a finding into a closed risk item. Deliverables include the important-business-service register, the third-party concentration analysis, the testing program, and the board-level reporting pack that demonstrates ongoing resilience oversight. Successful outcomes look like a tabletop where the recovery time inside the impact tolerance, a third-party register the regulator accepts, and an exit-plan exercise for a critical cloud or SaaS dependency that the firm has actually rehearsed. An engagement typically runs ten to sixteen weeks, embedded with operational risk, technology resilience, and the third-party risk function.

Third-party AI introduces a new class of vendor-risk exposure that the existing third-party-risk-management program was not designed to absorb: a model upstream changes weights without notice, a foundation-model provider deprecates an API, or a vendor's training data is challenged in litigation that propagates to the institution's outputs. The work begins with a third-party AI inventory, a contractual gap analysis against OCC Bulletin 2023-17, the EBA guidelines on outsourcing, and DORA's third-party ICT provisions where applicable. A senior consultant produces the model-supply-chain documentation that captures provenance, retraining triggers, and notice requirements; vendor-API governance that fences the institution's data flows and logging; and the contractual posture that includes audit rights, model-change notice clauses, kill-switch provisions, and exit-plan triggers proportional to criticality. Deliverables include the third-party AI register, a tiered due-diligence framework, model-output monitoring instrumented at the integration boundary, and a renegotiation playbook for material contracts. Successful outcomes look like a vendor-AI deployment the institution can pause within hours when an upstream change degrades output, a regulator examination that closes cleanly on third-party AI oversight, and contracts that survive a model deprecation event without extraordinary commercial concessions. An engagement typically runs eight to twelve weeks, embedded with third-party risk, procurement, the AI governance function, and one business-line owner of a material AI use case.