From Financial Regulation to Digital Control

Abstract

The increasing digitisation of financial services is changing how regulatory obligations are implemented, monitored and evidenced. In wealth management, areas such as suitability, advisory compliance, market-abuse surveillance, MiFID II and FinSA increasingly depend on interconnected data, applications, workflows and automated decision-support. This paper examines the relationship between financial regulation and information technology, with particular attention to RegTech, data governance, enterprise architecture, artificial intelligence and IT Product Management.

The paper argues that regulatory compliance should no longer be understood primarily as a legal or procedural function supported by technology. Instead, regulatory requirements are increasingly translated into technology-enabled organisational controls through data structures, business rules, workflows, identity and access controls, automation, monitoring and auditability. Consequently, the effectiveness of regulatory controls depends not only on the correctness of regulatory interpretation but also on data quality, integration architecture, system dependencies, human oversight and organisational accountability.

The analysis further argues that artificial intelligence intensifies this convergence. As AI moves from analytical support towards recommendations, decisions and autonomous actions, governance must extend beyond individual models to the wider AI-enabled process. Appropriate controls therefore need to address data provenance, decision rights, permissions, human intervention, monitoring, third-party dependencies, resilience and evidence. Human oversight must be meaningful rather than merely procedural, with clear authority to challenge and override automated outcomes where appropriate.

The paper concludes that the role of the IT Product Owner in regulated financial services extends beyond delivering software functionality. Product ownership increasingly involves translating regulatory objectives into controlled organisational capabilities that are measurable, auditable, resilient and adaptable to regulatory and technological change. The strategic shift is therefore from compliance applications towards organisational control, with IT architecture becoming an increasingly important component of the financial institution's overall regulatory control environment.

Keywords: wealth management; suitability; advisory compliance; market abuse; MiFID II; FinSA; RegTech; artificial intelligence; information technology; financial services; compliance technology; information systems

1. Introduction

Financial services regulation has traditionally been approached primarily as a legal and compliance function: organisations interpret regulatory obligations, establish policies and procedures, allocate responsibilities, and implement controls to manage regulatory risk. The increasing digitisation and automation of financial services, however, are changing how these obligations are translated into practice. Client onboarding, investment advice, portfolio management, trading, transaction monitoring, regulatory reporting and market surveillance increasingly depend on interconnected information systems. Compliance is therefore no longer implemented solely through policies and human judgement; it is increasingly embedded within the data, applications, workflows and technical controls through which financial services are delivered.

This transformation is particularly significant in wealth management. Digital platforms, analytics, automated decision-support and artificial intelligence (AI) are increasingly used to support client profiling, investment analysis, portfolio construction, advisory services and compliance activities. Recent research identifies a broadening application of AI across investment management, including portfolio optimisation, forecasting, risk management, robo-advisory and regulatory compliance, while also highlighting continuing challenges concerning governance, explainability, data and organisational adoption (Mertzanis, 2025). The implications extend beyond investment decision-making. As financial institutions increasingly rely on technology to mediate interactions between clients, advisers, products and markets, the technology itself becomes part of the environment through which regulatory obligations are fulfilled.

The same convergence is evident in RegTech. Research identifies the increasing use of big data, artificial intelligence, machine learning and automation to support regulatory compliance, fraud prevention, monitoring and financial-sector governance (El Khoury, Alshater and Joshipura, 2025). RegTech consequently represents more than the automation of existing compliance processes. It reflects a broader shift towards embedding regulatory requirements within organisational processes and information systems. Technology can increasingly determine which data must be collected, which activities are permitted, when intervention is required, what exceptions are generated, and what evidence is retained. Compliance therefore becomes partly an information architecture and control problem.

This is particularly apparent in domains such as suitability, advisory compliance and market abuse. Suitability depends upon the availability and quality of client information, investment objectives, financial circumstances, knowledge and experience, together with appropriate information about financial products and services. Advisory compliance requires organisations to integrate regulatory requirements into client and adviser workflows while maintaining appropriate documentation and evidence. Market-abuse prevention increasingly depends on the analysis of large and complex datasets, with machine-learning techniques providing new capabilities for identifying anomalous trading behaviour while retaining human investigation and judgement (Mazzarisi et al., 2024). These examples illustrate that regulatory effectiveness increasingly depends not simply on whether an organisation has established a policy, but on whether its systems can operationalise, monitor and evidence the corresponding control.

The same principle applies to MiFID II and Switzerland's Financial Services Act (FinSA). Although these frameworks arise from different legal and institutional contexts, both translate principles of investor protection, appropriate financial services, transparency, conduct, documentation and accountability into operational requirements for financial institutions. Their implementation therefore cuts across client data, product information, advisory processes, transaction systems, compliance rules, reporting infrastructure and audit records. Recent research on AI and MiFID II further demonstrates that the emergence of AI challenges traditional approaches to technology-neutral regulation, particularly where automated systems participate in investment services and decision-making (Azzutti, 2026). The regulatory question increasingly extends beyond whether a particular activity is permissible to whether the organisation can demonstrate that the technology supporting that activity operates within appropriate boundaries.

This creates a fundamental relationship between regulation and information technology. A regulatory obligation may originate in legislation or supervisory guidance, but its effectiveness increasingly depends on how that obligation is translated into data, rules, workflows, applications, controls, evidence and monitoring. The quality of the resulting control environment depends on data governance, system architecture, integration, identity and access management, automation, analytics, human oversight, auditability and the resilience of the underlying technology. Consequently, technology should not be regarded merely as an implementation mechanism operating downstream of regulatory policy. It is increasingly part of the organisational infrastructure through which regulatory obligations are interpreted, executed and demonstrated.

Against this background, this paper examines the relationship between IT and six closely connected domains of financial regulation and practice: wealth management, suitability, advisory compliance, market abuse, MiFID II and FinSA. It argues that these domains should be understood not only as regulatory or compliance disciplines, but also as socio-technical control environments. Their effective implementation requires the integration of regulatory interpretation with data, technology, business processes and human judgement. This perspective is particularly important as AI and automation become increasingly embedded within financial services. The central issue is therefore not simply whether technology can automate compliance, but whether organisations can design and govern technology in ways that preserve accountability, appropriate human judgement, transparency, auditability and control as financial services become increasingly digital and automated.

2. Wealth Management as a Technology-Intensive Business

Wealth management encompasses a broad range of financial services provided to affluent and high-net-worth clients, including investment advice, portfolio management, securities execution, financial planning and related advisory services. Traditionally, these activities have relied heavily on the relationship between the client and the relationship manager. Increasingly, however, this relationship is mediated and supported by digital platforms, data-driven analytics, automated decision-support and artificial intelligence (AI). Technology is therefore becoming not merely an enabler of wealth management, but an integral component of how financial services are delivered.

Digital wealth-management platforms bring together client information, financial circumstances, risk profiles, investment objectives, product information, portfolio data and market intelligence to support advisers and clients. Robo-advisory systems extend this model by automating elements of investor profiling, asset allocation and portfolio construction. Gaspar and Oliveira (2024) demonstrate how robo-advisers collect information about investor preferences, financial circumstances and objectives and use these inputs to develop investor profiles and investment recommendations. This illustrates an important shift: the technology does not simply present information to the adviser; it can participate directly in the process through which financial recommendations are generated.

The increasing use of AI further strengthens this relationship between technology and financial decision-making. Research on AI in investment management identifies applications across areas including portfolio optimisation, forecasting, risk management, investment analysis and compliance, while also highlighting challenges involving data, explainability, governance and organisational adoption (Mertzanis, 2025). More broadly, research on responsible AI governance emphasises that AI systems need to be considered within the organisational and decision-making environments in which they operate rather than governed solely as isolated technical artefacts (Papagiannidis, Mikalef and Conboy, 2025). In wealth management, this means that the design of technology can influence not only operational efficiency but also the information available to advisers, the recommendations presented to clients and the controls applied to financial activities.

From an IT perspective, this creates a highly interconnected information environment. A wealth-management platform may need to integrate client master data, financial circumstances, risk profiles, investment objectives, knowledge and experience, product information, market data, portfolio positions, transaction histories, sustainability preferences, regulatory classifications, adviser information, suitability requirements, investment restrictions and audit records. These data elements cannot be treated as independent technical attributes. Their meaning depends on the business and regulatory processes in which they are used, and changes to one element can have consequences across multiple downstream systems and controls.

Wealth-management technology should therefore be understood as a socio-technical system connecting clients, advisers, financial products, data, algorithms, regulatory rules and operational processes. This perspective is consistent with research emphasising that the organisational value of generative AI depends on its integration into actual workflows rather than its deployment as a standalone technology (Sarkar, 2026). Similarly, research on organisational adoption highlights the importance of technological, organisational and environmental conditions in determining whether AI becomes effectively embedded within business processes (Hughes et al., 2026). For wealth-management IT, the relevant question is consequently not simply whether a new technology can perform a particular task, but how it interacts with existing processes, responsibilities, controls and decision rights.

Robo-advisory provides a useful illustration of this principle. Scherer and Lehner (2025), analysing a large dataset of investor profiles, find that investment goals and time horizons materially influence recommended equity allocations, while robo-advisers also make practical compromises in balancing investment functionality with simplicity and accessibility. The finding demonstrates that apparently technical design choices can have substantive consequences for investment outcomes. Decisions concerning which client attributes are collected, how they are weighted, how they are translated into risk classifications and how recommendations are generated are simultaneously data, business, technology and regulatory decisions.

This has a direct implication for information-system design: the system must preserve the regulatory and business meaning of the information it processes. A risk-profile field, for example, is not simply a database attribute. Its value may influence which products can be recommended, which investment strategies are appropriate, which transactions require intervention and which compliance controls must be triggered. Similarly, client objectives, knowledge and experience, sustainability preferences and financial circumstances acquire operational significance only when they are reliably captured, interpreted and propagated through the relevant workflows and systems.

This makes data governance and system architecture central to wealth-management compliance. If critical client or product information is incomplete, outdated, inconsistent across systems or unavailable to the relevant decision process, downstream controls may be ineffective regardless of the sophistication of the application implementing them. The same principle applies to AI-enabled systems: responsible use requires appropriate data, defined decision boundaries, transparency, monitoring and human accountability (Papagiannidis, Mikalef and Conboy, 2025). Where AI becomes more autonomous, questions of identity, authority, access and oversight become increasingly important because the system may not merely recommend an action but influence or initiate it (Kshetri, 2025).

Human judgement consequently remains an important component of technology-enabled wealth management. AI and automated decision-support can process large volumes of information and identify patterns that would be difficult to detect manually, but their outputs operate within organisational decision processes rather than replacing accountability altogether. Research on AI-supported decision-making indicates that the effects of AI on decision quality depend on how humans and AI systems interact during the decision process (Zercher et al., 2025). For wealth management, this reinforces the importance of clearly defining where automation ends, where professional judgement begins and how exceptions, uncertainty and disagreements are handled.

The technology-intensive nature of wealth management therefore has implications extending beyond application functionality. Effective platforms must integrate data quality, regulatory rules, workflow orchestration, decision-support, identity and access management, auditability, monitoring and human oversight. They must also remain adaptable as products, regulations, client expectations and AI capabilities evolve. Wealth-management IT is consequently best understood not as a collection of front-end applications, but as an organisational control infrastructure through which client relationships, investment decisions and regulatory obligations are increasingly coordinated.

The central implication is that technology architecture and regulatory architecture are becoming increasingly interdependent. As digital and AI-enabled systems participate more directly in client profiling, investment recommendations and portfolio decisions, the quality of the financial service increasingly depends on the quality of the underlying information, rules, workflows and controls. Wealth management therefore provides a clear example of why financial regulation and IT can no longer be considered separate domains: the architecture of the technology increasingly determines how regulatory and business requirements are translated into operational decisions.

3. Suitability as a Digital Control Problem

Suitability provides one of the clearest examples of how financial regulation becomes an information-system and control problem. At a conceptual level, suitability requires a financial institution to understand the client sufficiently to determine whether a proposed investment service, strategy or financial instrument is appropriate in light of the client's circumstances and objectives. This requires the collection, interpretation and continuous use of information such as financial circumstances, investment objectives, risk tolerance, knowledge and experience.

From an IT perspective, suitability is therefore not a single compliance check performed at the end of an advisory process. It is a chain of interdependent data and decision controls connecting client information, client profiling, risk assessment, product characteristics, recommendation, suitability assessment, decision and evidence. The reliability of the final outcome depends on the integrity of each preceding component. A weakness at any stage can propagate through the process and result in an inappropriate recommendation or an inability to demonstrate that the relevant regulatory requirements were satisfied.

This creates several distinct technology risks. Poor or outdated client data can produce an inaccurate investor profile. An incomplete or inconsistent product taxonomy can result in incorrect classification of financial instruments. Defective or poorly governed rules can generate inappropriate recommendations. Integration failures can prevent relevant information from reaching the decision process. Finally, inadequate logging or audit trails can make it impossible to reconstruct which information, rules and assumptions contributed to a particular recommendation. Suitability is therefore dependent not only on regulatory interpretation but also on data quality, system architecture, integration, business rules and evidence management.

Research on robo-advisory reinforces this relationship between profiling methodology and technological design. Gaspar and Oliveira (2024) demonstrate that robo-advisers can use different methodologies to determine investor profiles and highlight limitations in the transparency of the underlying profiling process. This is significant from an IT perspective because the methodology used to transform client information into a risk or investor profile can materially influence the resulting investment recommendation. The technical implementation of profiling is therefore also part of the regulatory control environment.

The implication is that suitability should be understood as a continuous control process embedded within the investment workflow rather than as an isolated compliance activity. Client circumstances and objectives can change; products and investment strategies evolve; regulatory requirements are amended; and the information available to the institution may be updated from multiple sources. A robust suitability architecture must therefore support the controlled collection, validation, transformation, use and monitoring of relevant information throughout the client lifecycle.

This creates several core requirements for IT.

First, client data must be governed. The organisation needs confidence that information used in suitability assessments is accurate, sufficiently complete, current, appropriately sourced and available to the systems and individuals responsible for the decision. Data lineage is particularly important where information is aggregated from multiple applications or external sources.

Second, product data must be governed. The system must represent relevant characteristics of financial instruments and investment strategies, including factors such as risk, complexity, liquidity and investment horizon where applicable. Product information must also remain sufficiently consistent across the applications involved in advisory and investment processes.

Third, regulatory requirements must be translated into explicit and testable controls. Requirements cannot remain exclusively within policies or procedural documents when organisations rely on technology to perform or support regulated activities. Where appropriate, regulatory rules need to be translated into executable business logic, decision rules, workflow controls or validation mechanisms. This creates a direct connection between regulatory interpretation and software design.

Fourth, decisions must be reconstructable. An organisation should be able to establish what information was available at the relevant point in time, how that information was interpreted, which rules or models were applied, what recommendation was produced and whether a human adviser subsequently accepted, modified or rejected the outcome. Auditability therefore requires more than retaining the final decision; it requires sufficient evidence of the decision process itself.

This requirement becomes more significant as AI is introduced into investment and advisory processes. Mertzanis (2025) identifies AI-driven investment management, advisory, risk management and compliance as important areas of development, while highlighting governance and explainability as continuing challenges. The use of AI therefore introduces an additional control dimension: organisations must consider not only whether the underlying data and regulatory rules are correct, but also how an AI-enabled system transforms those inputs into recommendations or decisions.

The challenge is particularly important where AI systems influence rather than merely support human judgement. Research on AI-supported decision-making suggests that outcomes depend partly on how humans interact with AI during decision processes, rather than on the technical capabilities of the AI system alone (Zercher et al., 2025). In a suitability context, this means that human oversight must be designed into the workflow. The relevant question is not simply whether an adviser remains formally responsible, but whether the adviser has sufficient information, authority and understanding to challenge an automated recommendation when circumstances require it.

This also creates a governance requirement around model and decision logic. AI-enabled profiling or recommendation systems should operate within clearly defined boundaries concerning the data they can access, the decisions they can influence and the actions they can initiate. As AI becomes more autonomous, questions of identity, access, authority and oversight become increasingly important because a system may move from generating an analytical output towards participating directly in a business process (Kshetri, 2025). In such circumstances, access controls, logging, monitoring and intervention mechanisms become part of the suitability control framework.

Suitability therefore illustrates a broader principle concerning the relationship between regulation and IT: a regulatory obligation becomes an IT control when an organisation depends on information systems to determine, constrain, recommend, execute or evidence regulated activity. The control is not located in a single application or rules engine. It emerges from the interaction of data governance, business rules, system architecture, workflow design, AI or decision-support capabilities, human judgement and auditability.

This perspective also changes how suitability should be approached by IT Product Owners and technology leaders. The objective is not simply to implement a compliance requirement in software. It is to design a control environment in which regulatory intent is reliably translated into data, rules, workflows, decisions and evidence. Effective suitability technology must therefore be accurate, explainable, traceable, testable and adaptable, while preserving appropriate human accountability. As financial advice becomes increasingly digital and AI-enabled, the quality of the suitability control will depend increasingly on the quality of the information architecture through which that advice is produced.

4. Advisory Compliance and the Digitisation of Human Judgement

Advisory compliance concerns the conduct of financial advice and the protection of clients from inappropriate recommendations, inadequate disclosure, conflicts of interest and other forms of misconduct. In traditional wealth management, these controls have relied substantially on the professional judgement of the relationship manager, supported by policies, procedures and supervisory review. Increasingly, however, advisory processes are mediated by digital platforms, decision-support systems, automated workflows and artificial intelligence (AI). The result is a shift from predominantly human-controlled advice towards technology-mediated decision-making.

The modern adviser may interact with systems that retrieve client information, calculate risk profiles, identify potentially suitable products, generate recommendations, provide product documentation, produce disclosures, record client interactions, flag exceptions, require approvals and maintain evidence for compliance and audit. These capabilities can improve consistency, efficiency and transparency, but they also change the nature of the control environment. The adviser is no longer making a decision independently of the technology; rather, the decision is increasingly shaped by the information, recommendations, constraints and workflow presented by the system.

This creates an important distinction between automation and accountability. A technology system can support, constrain or even partially automate a decision without becoming accountable for the regulatory outcome. Recent research on AI and MiFID II highlights this challenge, arguing that the increasing use of AI in financial services does not remove the regulatory responsibilities of the institutions deploying it. Technological neutrality therefore cannot be interpreted as regulatory neutrality: where AI participates in investment services, the regulated organisation remains responsible for ensuring that the relevant regulatory requirements are satisfied (Azzutti, 2026).

The distinction is consistent with broader research on responsible AI governance, which emphasises that governance must extend beyond the technical characteristics of an AI model to the organisational context in which the system is deployed (Papagiannidis, Mikalef and Conboy, 2025). In advisory compliance, this means that accountability cannot be delegated simply because a recommendation is generated algorithmically. The organisation must establish who is responsible for the system, who can challenge its outputs, under what circumstances intervention is required and how decisions can subsequently be reviewed.

The implications for IT architecture are substantial. A well-designed advisory platform may combine automated recommendations with confidence or exception indicators, human review, mandatory intervention thresholds, override mechanisms, reason capture, decision logging and post-decision monitoring. These mechanisms transform human judgement from an informal safeguard into an explicit component of the technology-enabled control process.

This represents a shift from the simplistic concept of a “human-in-the-loop” towards meaningful human control. Merely requiring an adviser to click an approval button does not necessarily constitute effective oversight. Meaningful control requires the human decision-maker to have sufficient information, context, authority and time to understand and challenge the system's recommendation. The system must also make intervention possible rather than merely presenting an automated conclusion for formal approval.

This distinction is particularly important because automation can create a risk of automation bias. Where system-generated recommendations appear authoritative, advisers may place excessive reliance on them, particularly when the underlying methodology is complex or difficult to interrogate. Research on human–AI decision-making suggests that the quality of outcomes depends not only on the capabilities of AI but also on how AI is incorporated into the decision process and how human participants interact with its outputs (Zercher et al., 2025). The design of the surrounding workflow is therefore as important as the design of the AI model itself.

The same principle can be understood through the broader concept of workflow integration. Research on organisational adoption of generative AI suggests that the value and risks of AI depend on how effectively it becomes embedded within existing organisational structures, processes and responsibilities (Hughes et al., 2026). Sarkar (2026) similarly emphasises the importance of moving beyond AI experimentation towards integration into actual organisational workflows. For advisory compliance, this means that an AI recommendation engine cannot be evaluated independently from the client data, product systems, adviser workflow, approval mechanisms and compliance controls surrounding it.

This creates several requirements for technology design. First, the provenance of a recommendation should be sufficiently transparent for the relevant human decision-maker to understand the principal information and logic influencing the outcome. Second, decision rights should be explicit, defining what the system may recommend, what it may prevent and what requires human intervention. Third, exceptions and overrides should be governed, with appropriate reasons captured and retained. Fourth, decisions should be auditable, allowing the organisation to reconstruct the information and system state relevant to the decision. Finally, post-decision monitoring should identify patterns of inappropriate recommendations, repeated overrides, unusual adviser behaviour or systematic weaknesses in the technology.

These requirements become more significant as AI systems become increasingly capable and autonomous. Where an AI system can access multiple sources of client and product information, generate recommendations and trigger subsequent workflow actions, governance must extend to the system's identity, permissions, authority and ability to act. Kshetri (2025) highlights the growing importance of security, identity and oversight as AI systems become more agentic. In financial services, this suggests that access management and technical permissions are not merely cybersecurity controls; they can also determine the practical boundaries of AI-enabled decision-making.

Advisory compliance therefore illustrates a broader transformation in the relationship between human judgement and technology. The objective is not to eliminate professional judgement through automation, nor to preserve human involvement merely as a formal compliance requirement. Rather, the objective is to design systems in which technology performs those activities for which automation provides value while human decision-makers retain meaningful authority over decisions that require contextual judgement, interpretation or accountability.

From an IT Product Management perspective, this means that advisory technology should be designed around decision rights rather than functionality alone. Product requirements should identify what information the system requires, what decisions it can support, what constraints it must enforce, when human intervention is mandatory, what evidence must be retained and how exceptions are handled. The resulting product is therefore not simply an application for financial advice; it is a technology-enabled control environment in which regulatory requirements, data, algorithms, workflows and human judgement interact.

The central principle is that digitising advisory processes does not digitise accountability. As technology increasingly influences financial advice, effective compliance depends on maintaining meaningful human control while making automated decisions transparent, traceable, testable and appropriately constrained. The sophistication of an AI-enabled recommendation is therefore less important than the organisation's ability to demonstrate that the recommendation was generated and acted upon within a controlled, accountable and auditable decision process.

5. Market Abuse and the Emergence of Data-Driven Surveillance

Market-abuse compliance represents a different but complementary technology challenge to suitability and advisory compliance. Whereas suitability focuses primarily on determining whether a financial service, product or recommendation is appropriate for a particular client, market-abuse surveillance focuses on identifying potentially inappropriate behaviour within financial markets. The former is therefore largely a preventive, client-specific control, while the latter is predominantly a continuous, data-driven detection and investigation process.

Market abuse encompasses behaviours such as insider dealing and market manipulation. Detecting such behaviour is technically difficult because potentially suspicious activity can be embedded within very large volumes of legitimate transactions and communications. The relevant signals may also be distributed across different systems, time periods, instruments and market participants. Consequently, effective surveillance depends not only on the sophistication of analytical models but also on the institution's ability to integrate and interpret data across organisational and technological boundaries.

This makes market-abuse surveillance particularly suited to advanced analytics and machine learning. Mazzarisi et al. (2024), for example, demonstrate an unsupervised machine-learning approach to insider-trading detection that combines clustering and network-based techniques to identify unusual trading behaviour around price-sensitive events and potential relationships between synchronised traders. Their work illustrates how analytical techniques can identify patterns that may be difficult to detect through conventional rule-based surveillance alone.

The underlying architecture can be understood as a continuous chain connecting market data, transaction data, investor and trader identity, event information and historical behaviour to analytical models, anomalies, alerts, investigation and evidence. Each component introduces its own control requirements. Incomplete transaction data may obscure suspicious activity; inconsistent identity information may prevent transactions from being correctly associated with an individual or entity; inadequate event data may weaken the contextual interpretation of trading behaviour; and poor integration between surveillance and case-management systems may compromise subsequent investigation.

This illustrates an important principle: the effectiveness of surveillance is constrained by the quality and integration of the data on which it depends. A highly sophisticated machine-learning model cannot compensate for missing, inconsistent or poorly governed source data. Market-abuse surveillance therefore requires strong data governance, common identifiers, reliable timestamps, appropriate retention, data lineage and controlled integration across trading, client, market and compliance systems.

The role of AI in this environment must also be clearly distinguished from the regulatory determination of misconduct. An AI or machine-learning model does not, by itself, establish that market abuse has occurred. Rather, it identifies patterns or anomalies that may justify further examination. Mazzarisi et al. (2024) explicitly position machine learning as supporting the initial stages of detection and investigation rather than replacing the judgement of the relevant investigators or competent authorities.

This distinction is critical because surveillance involves a fundamental trade-off between sensitivity and investigative efficiency. A system designed to identify as many potential anomalies as possible may generate a large number of false positives, overwhelming investigators and reducing the practical value of the surveillance function. Conversely, a system designed too narrowly may fail to identify genuinely suspicious behaviour. The objective is therefore not simply maximum predictive accuracy, but an effective end-to-end surveillance process in which alerts are appropriately generated, prioritised, investigated and resolved.

For IT, this creates requirements that extend beyond the analytical model itself. Surveillance systems need to support explainability so that investigators can understand why an alert was generated; effective false-positive management so that investigative capacity is directed towards higher-risk cases; intuitive investigator interfaces; preservation of relevant evidence; reliable data lineage; appropriate alert prioritisation; model-performance monitoring; auditability; and integration with case-management and reporting systems.

Explainability is particularly important where machine-learning techniques are used in regulatory surveillance. Investigators need to understand the principal factors contributing to an alert in order to assess its relevance, challenge the analytical output and determine what additional evidence should be examined. The objective is not necessarily to expose every internal computational mechanism of a complex model, but to provide sufficient information to support a defensible investigative decision. This aligns with the broader governance principle that AI systems should be embedded within organisational processes that preserve accountability and meaningful human oversight (Papagiannidis, Mikalef and Conboy, 2025).

The same principle applies to model monitoring. Financial markets evolve, trading strategies change, new instruments are introduced and patterns of potentially abusive behaviour can adapt to changes in market structure and technology. A model that performs effectively under one set of conditions may therefore become less effective over time. AI governance consequently needs to extend beyond initial model validation to ongoing monitoring, testing, performance assessment and controlled change. This reflects the broader view that responsible AI governance is an organisational process rather than a one-time technical assessment (Batool, Zowghi and Bano, 2025).

Market-abuse surveillance also illustrates the importance of resilience. Surveillance is a critical control function, and its failure may result not simply in operational inconvenience but in the inability to detect or investigate potentially serious regulatory breaches. The resilience of the surveillance environment therefore depends on the availability, integrity and recoverability of its underlying data, analytical services, identity infrastructure and case-management capabilities. More broadly, research on organisational cyber resilience emphasises the need to consider resilience across interconnected organisational and technological dependencies rather than treating individual systems in isolation (Neri, Niccolini and Virili, 2026).

As AI becomes more capable, surveillance may also become increasingly adaptive. Systems could potentially correlate larger numbers of data sources, identify complex behavioural patterns and dynamically prioritise investigations. However, increasing analytical capability also increases the importance of governance. The organisation must be able to establish which data the system can access, how models are changed, who can modify detection thresholds, who can close or escalate alerts and how investigative decisions are recorded. Identity, access management and decision rights therefore become part of the surveillance control environment rather than merely technical security functions.

Market-abuse surveillance consequently represents a useful example of data-driven regulatory control. The technology does not replace the regulatory judgement required to determine whether misconduct has occurred. Instead, it expands the organisation's ability to identify potentially significant patterns within complex and high-volume data and to direct human investigative attention towards them.

From an IT Product Management perspective, this changes the definition of the product. The product is not simply a machine-learning model that produces alerts. It is an integrated surveillance and investigation capability encompassing data ingestion, identity resolution, analytical models, alert generation, prioritisation, investigator workflows, evidence management, case handling, monitoring and reporting. Product success should therefore be assessed not only through model-level metrics but also through the effectiveness, reliability and auditability of the complete investigation process.

Market abuse thus demonstrates a broader principle established throughout this paper: regulatory technology is most effective when the analytical capability is designed as part of an end-to-end control process. In market surveillance, the value of AI lies not in autonomously declaring misconduct, but in improving the organisation's ability to detect, investigate, evidence and respond to potentially abusive behaviour while preserving human accountability and regulatory control.

6. MiFID II: From Regulation to Information Architecture

MiFID II provides a particularly clear example of how financial regulation translates into extensive and distributed information-system requirements. Its objectives include investor protection, market integrity, transparency and appropriate conduct of business. These objectives are operationalised through requirements relating to client classification, suitability and appropriateness, product governance, best execution, transaction reporting, record keeping and conflicts of interest. Although these obligations originate in a regulatory framework, their effective implementation depends increasingly on the design and integration of the information systems supporting financial activities.

The significance for IT lies in the fact that MiFID II requirements cut across multiple business processes and technology platforms. Suitability, for example, may require information to move between customer relationship management systems, client master data, risk-profiling services, product catalogues, portfolio-management platforms, order-management systems, advisory applications, compliance engines and audit repositories. The resulting control is therefore distributed across a technology landscape rather than contained within a single application.

Similarly, transaction reporting depends on a sequence of interconnected capabilities linking trade execution, transaction data, instrument and reference data, reporting logic, regulatory reporting, reconciliation and exception management. Best execution introduces another combination of transaction data, market information, execution venues, pricing information and execution-quality analysis. The implementation challenge is therefore not simply to automate individual regulatory obligations, but to ensure that information remains accurate, consistent and traceable as it moves across multiple systems and organisational processes.

MiFID II should consequently be understood as creating a distributed regulatory architecture. Regulatory controls emerge from the interaction of data, applications, integration mechanisms, business rules, workflows and human responsibilities. This makes architecture and data governance central to regulatory compliance. A control may appear effective within an individual application while failing at the wider process level because information is incomplete, inconsistent, delayed or transformed incorrectly between systems.

Research into the implementation of MiFID II investor-protection requirements within private banks illustrates this operational complexity. Van der Woude et al. (2022), drawing on interviews with representatives from 25 private banks across ten European Union countries, examine how institutions implement investor-protection requirements such as suitability and manage associated risks. Their findings illustrate that regulatory implementation involves organisational processes and risk-management practices rather than the straightforward deployment of an individual technological control.

This has important implications for IT governance. Regulatory requirements must be translated into system capabilities while maintaining traceability between the regulatory objective and its technical implementation. Changes to regulation may therefore require coordinated changes across data models, business rules, interfaces, workflows, applications, reporting mechanisms and controls. Without clear ownership and dependency management, a change in one regulatory requirement can create inconsistent implementations across the technology landscape.

The challenge becomes more significant as AI is introduced into investment services. Azzutti (2026) argues that the technology-neutral approach of MiFID II remains valuable because regulatory objectives should continue to apply irrespective of the technology through which financial services are delivered. At the same time, the increasing use of AI creates heterogeneous risks that may not be fully addressed by an activity-based framework alone. This creates a tension between technology-neutral regulation and technology-specific control requirements.

The distinction is important for IT because AI-enabled investment services can take many forms. They may include automated client profiling, algorithmic recommendations, portfolio optimisation, natural-language interfaces, generative AI, automated reporting and AI-assisted compliance. Each capability can introduce different risks concerning data quality, explainability, model performance, security, accountability and human oversight. The regulatory obligation may remain constant while the technical mechanisms through which the obligation is implemented change substantially.

This suggests that regulatory compliance cannot be treated as a static software feature. AI systems evolve through changes in models, training data, prompts, configurations, integrations and underlying services. Consequently, the relevant control environment must address the lifecycle of the technology, not simply its initial deployment. Responsible AI governance research similarly emphasises that governance must encompass organisational structures, processes and controls surrounding AI rather than focusing exclusively on model characteristics (Papagiannidis, Mikalef and Conboy, 2025).

The lifecycle perspective also has implications for change management. A modification to an AI model or an underlying data source may alter the behaviour of a system that supports regulated activity even when the regulatory requirement itself has not changed. Technology governance therefore needs mechanisms for version control, testing, validation, approval, monitoring and rollback. Where an AI-enabled system is materially involved in investment decisions or compliance processes, these mechanisms become part of the regulatory control environment.

The distributed nature of MiFID II also makes data lineage and auditability particularly important. An organisation should be able to trace relevant information from its original source through transformations, business rules and system interfaces to the resulting decision, transaction or regulatory report. This is particularly important where multiple applications contribute to the final outcome. Without adequate lineage, it can become difficult to establish whether a regulatory control operated as intended or to identify where a failure occurred.

The same principle applies to accountability. Because MiFID II controls frequently span organisational boundaries, responsibility cannot be defined solely at application level. Product owners, business owners, Compliance, Risk, architecture teams, data owners and technology teams may each control different components of the overall process. Effective governance therefore requires clear ownership of the end-to-end regulatory outcome, supported by transparency over dependencies, risks, exceptions and change.

AI further reinforces the need for meaningful human oversight. Where AI systems provide recommendations or influence investment decisions, human involvement should be defined in terms of actual decision rights rather than merely formal approval. Research on AI-supported decision-making indicates that the effects of AI depend significantly on how human and AI capabilities are combined within decision processes (Zercher et al., 2025). In the MiFID II context, this means that organisations need to determine where automated decision-making is appropriate, where human intervention is required and how those decisions are evidenced.

MiFID II therefore demonstrates that financial regulation increasingly functions as an information-architecture requirement. Its obligations are translated into data structures, business rules, application capabilities, integration services, workflows, monitoring mechanisms and evidence repositories. The regulatory framework may be technology-neutral at the level of principle, but its effective implementation necessarily depends on technology-specific design decisions.

From an IT Product Management perspective, the consequence is significant. A Product Owner responsible for a regulatory capability cannot treat the relevant application as an isolated product. The product must be understood in the context of the broader regulatory process, its upstream and downstream dependencies, the data on which it relies, the controls it implements and the evidence it produces. Product ownership therefore needs to extend beyond feature delivery towards end-to-end regulatory outcomes, architectural dependencies and sustainable control effectiveness.

MiFID II ultimately illustrates a central argument of this paper: regulation becomes operational through information architecture. As financial services become increasingly digital and AI-enabled, regulatory compliance depends not only on interpreting what the rules require, but on designing technology environments capable of implementing, monitoring, evidencing and adapting those requirements over time.

7. FinSA and the Swiss Regulatory Technology Environment

For Swiss financial institutions, the Financial Services Act (FinSA) provides an important domestic framework for the regulation of financial services and the protection of clients. Although FinSA and MiFID II arise from different legal and institutional contexts and should not be treated as identical regulatory regimes, they address several related areas, including client classification, information and disclosure requirements, suitability and appropriateness, documentation and conduct. Their implementation therefore creates comparable challenges for financial institutions that must translate regulatory principles into operational processes and technology-enabled controls.

The IT relevance follows the same underlying logic established in the preceding sections. FinSA requirements ultimately need to be reflected in the information and processes through which financial services are delivered. Depending on the applicable service and client relationship, this can involve client data, client classification, adviser workflows, product information, suitability or appropriateness assessments, disclosures, documentation, exception handling, record retention and audit evidence. The regulatory requirement therefore becomes operational only when the organisation can reliably capture the relevant information, apply the appropriate control and retain sufficient evidence of its operation.

This illustrates why the distinction between Compliance and IT becomes increasingly artificial at the point of regulatory implementation. Compliance determines what needs to be controlled and interprets the regulatory requirements. The business determines how financial services should operate and how clients and advisers interact with the organisation. Technology determines how these requirements can be implemented consistently, securely and at scale. The effective control environment emerges from the interaction of all three.

The Product Owner or technology leader therefore occupies an important position at this intersection. The role is not simply to translate a Compliance requirement into a software feature. It involves understanding the underlying regulatory objective, challenging ambiguous or inefficient requirements where appropriate, identifying dependencies across business processes and systems, and designing a solution that is operationally effective and sustainable. This is consistent with the broader view of responsible technology governance in which organisational processes, responsibilities and technical controls need to operate as an integrated system (Papagiannidis, Mikalef and Conboy, 2025).

The challenge becomes particularly significant for international financial institutions. A single business process may involve multiple legal entities, jurisdictions, client types, products and regulatory regimes. The same underlying activity may therefore be subject to different requirements depending on where the client is located, which entity provides the service, which product is involved and which regulatory framework applies.

From an enterprise-architecture perspective, this can be represented conceptually as a sequence of determinations connecting client, jurisdiction, legal entity, service, product, regulatory regime and applicable controls. The technology challenge is consequently not simply to encode an individual regulatory rule, but to establish a flexible architecture capable of determining which rules and controls apply to a particular business context.

This introduces the concept of regulatory context as a system capability. Rather than embedding jurisdiction-specific logic independently within multiple applications, an organisation can seek to establish common data, rules and services that determine the relevant regulatory context and make that context available to downstream processes. Such an approach can reduce duplication, improve consistency and make regulatory change easier to manage. At the same time, it requires careful governance because an incorrect regulatory classification can propagate incorrect controls across multiple downstream processes.

The importance of this architecture increases as institutions operate across multiple markets. Regulatory requirements may differ not only between jurisdictions but also according to client classification, service type, product characteristics and legal entity. Technology must therefore support controlled variation without creating uncontrolled fragmentation. This is fundamentally an architecture and product-management challenge: common capabilities should be standardised where appropriate, while jurisdiction-specific requirements must remain sufficiently configurable to reflect genuine regulatory differences.

The same principle applies to data governance. If client classification, jurisdiction, legal-entity information or product attributes are inconsistent across systems, downstream regulatory controls may be applied incorrectly. Data quality is therefore not simply an operational concern; it can determine which regulatory obligations the system believes are applicable. In this sense, master data, reference data and regulatory classifications become part of the control infrastructure itself.

AI introduces an additional dimension to this environment. As financial institutions increasingly use AI for advisory support, client analysis, document generation, compliance monitoring or other activities, the applicable regulatory context must remain visible throughout the AI-enabled workflow. An AI system should not be allowed to operate outside the regulatory boundaries established for the relevant client, service, entity and jurisdiction. Where AI systems become more autonomous, identity, permissions and oversight become particularly important because technical authority increasingly determines what the system is capable of doing (Kshetri, 2025).

This also reinforces the importance of responsible AI governance. AI governance cannot be separated from the organisational and regulatory context in which an AI system operates. The relevant controls need to address not only model behaviour but also data, workflows, responsibilities, human oversight and the organisational processes surrounding the system (Batool, Zowghi and Bano, 2025; Papagiannidis, Mikalef and Conboy, 2025). For a Swiss financial institution operating internationally, this means that AI governance may need to account for differences in regulatory requirements across jurisdictions while maintaining consistent enterprise-level principles.

FinSA therefore provides a useful example of how regulatory technology operates in practice. The central challenge is not simply converting legislation into software rules. It is creating an architecture in which regulatory context, client information, business processes, product characteristics and control requirements can interact reliably. The resulting technology environment must be sufficiently standardised to provide consistency and sufficiently flexible to accommodate legitimate regulatory variation.

From an IT Product Management perspective, this requires product boundaries to be defined around business and regulatory outcomes rather than individual applications. A regulatory product may depend on several upstream data sources, shared services, workflow platforms and downstream controls. Product ownership must therefore include visibility over dependencies, regulatory change, data quality, architectural constraints and control effectiveness. This is particularly important where multiple Product Owners contribute to different parts of the same regulatory process.

The Swiss regulatory technology environment consequently illustrates a broader principle: effective regulatory technology requires both standardisation and controlled flexibility. Standardisation creates consistency in data, controls and governance, while configurable regulatory logic allows the organisation to respond to differences in jurisdiction, client type, service and product. The strategic challenge is to achieve both without allowing the technology landscape to become fragmented, opaque or unnecessarily complex.

FinSA thus reinforces the central argument of this paper. Regulation does not become operational simply because an organisation has interpreted the legal requirement correctly. It becomes operational when the organisation can reliably determine which requirement applies, to whom, in which context, through which process and with which evidence. This makes regulatory context, data architecture, workflow integration and product governance fundamental components of modern financial-services compliance.

8. RegTech as the Convergence of Compliance and IT

The emergence of RegTech provides perhaps the clearest illustration of the convergence between regulatory compliance and information technology. RegTech is increasingly concerned not simply with automating individual compliance activities, but with embedding regulatory requirements within the data, processes, systems and decision-making mechanisms through which financial institutions operate.

El Khoury, Alshater and Joshipura (2025) identify several major themes in RegTech research, including applications within financial services and banking regulation, compliance and fraud prevention, digital transformation and governance, and the integration of big data, artificial intelligence, machine learning and blockchain. This breadth demonstrates that RegTech has evolved beyond the narrow automation of compliance tasks. It increasingly represents a technology-enabled approach to managing regulatory complexity across the organisation.

RegTech should therefore not be understood simply as software purchased and operated by the Compliance function. It represents a broader organisational capability in which regulatory requirements are translated into data structures, business rules, workflows, analytical models, controls and evidence. Compliance remains responsible for interpreting regulatory obligations and defining the required control outcomes, but technology increasingly determines how consistently and efficiently those outcomes can be implemented.

This convergence changes the traditional relationship between Compliance and IT. Under a conventional model, Compliance may define a requirement, operational teams may establish procedures and IT may provide supporting applications. Under a more mature RegTech model, regulatory requirements are incorporated directly into the processes through which business activities are performed. The control becomes part of the operating model rather than a separate activity performed after the transaction or client interaction has occurred.

Charoenwong et al. (2024) provide important empirical evidence for this transformation. Their research finds that firms subject to new internal-control requirements make significant technology investments and that these investments can subsequently support broader organisational activities. This suggests that compliance-driven technology investment can generate capabilities extending beyond the original regulatory objective.

For example, improved client data initially collected to support KYC, client classification or suitability may subsequently support customer analytics, relationship management, risk management, fraud detection, regulatory reporting, AI applications and operational efficiency. Similarly, a common identity and access-management capability introduced to strengthen regulatory controls can support cybersecurity, segregation of duties, operational resilience and broader enterprise governance. Regulatory investment can therefore create reusable organisational infrastructure.

This creates an important distinction between compliance cost and compliance capability. A narrowly designed regulatory solution may satisfy an immediate requirement but create another isolated application, duplicated data and additional operational complexity. A well-designed RegTech capability can instead strengthen the organisation's underlying information architecture and provide reusable services for multiple business and regulatory purposes.

The concept is closely related to the broader importance of workflow integration. Research on organisational adoption of generative AI suggests that the value of new technology depends significantly on how effectively it becomes embedded within existing organisational processes rather than operating as a separate technical capability (Hughes et al., 2026). Sarkar (2026) similarly emphasises the importance of integrating AI into real organisational workflows. The same principle applies to RegTech: technology creates the greatest value when regulatory controls are integrated into the processes in which the underlying business activity occurs.

This supports the concept of compliance-by-design. Rather than performing a business activity first and applying compliance checks afterwards, organisations can incorporate relevant controls into the process itself. A client cannot proceed without the required classification; a transaction can be constrained by applicable restrictions; an advisory workflow can require relevant suitability information; a potential surveillance event can automatically enter an investigation workflow; and regulatory reporting can be generated from controlled transaction data.

Compliance-by-design can improve both regulatory effectiveness and operational efficiency, but it also increases the importance of the underlying architecture. When a regulatory control is embedded directly into a business process, an incorrect rule, inaccurate data element or defective integration can affect the business activity itself. The technical quality of the control therefore becomes inseparable from the quality of the business process.

This also means that RegTech introduces new forms of technology risk. Increasing dependence on automated controls creates potential risks associated with data quality, system availability, model performance, integration failures, cyber threats and third-party dependencies. The resilience of RegTech therefore needs to be considered as part of the overall regulatory control environment. Organisational resilience research reinforces the importance of understanding critical dependencies across interconnected technological and organisational systems rather than assessing individual systems in isolation (Neri, Niccolini and Virili, 2026).

AI further expands this challenge. AI-enabled RegTech can support activities such as anomaly detection, document analysis, transaction monitoring, regulatory interpretation, workflow prioritisation and risk assessment. However, AI introduces additional requirements around explainability, model governance, human oversight and accountability. Responsible AI research emphasises that governance needs to encompass the organisational context surrounding AI rather than focusing exclusively on the technical model (Papagiannidis, Mikalef and Conboy, 2025). RegTech therefore increasingly requires governance mechanisms capable of addressing both conventional software controls and adaptive AI-enabled capabilities.

The emergence of AI also strengthens the case for treating regulatory technology as a product rather than a collection of projects. A regulatory product has users, business outcomes, regulatory obligations, data dependencies, operational risks and a lifecycle. Its roadmap must respond not only to regulatory change but also to changes in business processes, technology capabilities, risk exposure and user expectations. This requires continuous prioritisation and investment rather than a one-time implementation.

From an IT Product Management perspective, the central question therefore becomes: what reusable capability can be created to satisfy the regulatory requirement while improving the organisation's broader operating model? This shifts the focus from delivering a compliance feature to developing sustainable capabilities in data, workflow, analytics, automation and control.

RegTech consequently represents more than the convergence of two professional disciplines. It reflects a deeper transformation in how financial institutions organise regulatory control. Compliance defines the required outcomes; business processes provide the operational context; and technology provides the mechanisms through which those outcomes can be implemented, monitored and evidenced. The boundaries between these functions increasingly become organisational rather than technological.

The strategic opportunity is therefore to move from compliance as an additional layer of control towards compliance embedded within the architecture of the business itself. When designed effectively, RegTech can make regulatory controls more consistent while simultaneously creating reusable data, technology and process capabilities. Compliance technology can consequently become not merely a cost of regulation, but an enabler of operational efficiency, risk management and digital transformation.

9. Artificial Intelligence and the New Compliance Architecture

Artificial intelligence (AI) intensifies the convergence between financial regulation and information technology. AI can strengthen compliance by analysing large and complex datasets, identifying anomalous behaviour, extracting information from unstructured documents, generating summaries, supporting risk assessment and assisting human decision-making. In investment management, research identifies applications across portfolio management, advisory services, risk management, fraud detection and regulatory compliance, while also highlighting continuing challenges around governance, explainability and organisational adoption (Mertzanis, 2025).

The introduction of AI therefore creates a dual effect. On the one hand, it can increase the organisation's ability to implement regulatory controls at scale. On the other, it introduces new sources of technological and organisational risk. A system that relies on AI may be affected by data quality, model validity, explainability, bias, model drift, cybersecurity threats, privacy concerns, third-party dependencies, inadequate human oversight, insufficient monitoring or weak auditability. The compliance challenge consequently shifts from determining whether an AI model performs a particular task effectively towards determining whether the complete AI-enabled process remains within appropriate regulatory and organisational boundaries.

This is particularly important because AI systems can operate at different levels of influence. An AI application may simply retrieve information or generate a summary; it may recommend a product or investment strategy; it may prioritise compliance cases; or it may initiate actions within a workflow. These different levels of capability create different consequences and therefore different governance requirements. Azzutti (2026) highlights the heterogeneous risks associated with AI in financial services and argues for approaches that account for the specific characteristics and risks of different applications rather than assuming that a single governance model is sufficient for every use case.

This supports a risk-proportionate approach to AI governance. The appropriate level of control should reflect factors such as the sensitivity of the data involved, the importance of the financial decision, the degree of automation, the autonomy of the system, the potential consequences of error and the organisation's ability to detect and intervene when something goes wrong. A system that summarises internal documents does not necessarily require the same control environment as an AI system that influences investment recommendations or initiates client-related actions.

The broader literature on responsible AI similarly indicates that governance cannot be reduced to model-level controls. Effective governance requires organisational structures, processes and responsibilities capable of managing AI throughout its operational lifecycle (Papagiannidis, Mikalef and Conboy, 2025). Batool, Zowghi and Bano (2025) likewise identify AI governance as a broad and evolving field encompassing multiple organisational and technical dimensions. The implication for financial services is that AI governance must extend beyond model approval and encompass the data, workflow, users, controls and decisions surrounding the technology.

This creates a fundamental shift in the appropriate unit of governance. Traditional technology governance often focuses on individual applications, systems or models. In AI-enabled financial services, however, the relevant control environment may be the entire business process in which the AI operates. A wealth-management process, for example, may connect client data, AI-enabled profiling, investment recommendations, suitability assessment, human review, transaction execution, monitoring and audit. Governance of the AI model alone would not adequately address risks arising from the surrounding data, workflow or decision-making process.

The resulting architecture can be understood as a sequence connecting client data, AI analysis or profiling, recommendation, suitability assessment, human review, transaction, monitoring and audit. Each stage represents a potential control point. Data controls determine whether the AI receives reliable information. Model controls determine whether the analytical capability behaves as intended. Workflow controls determine what the system is permitted to recommend or initiate. Human controls determine where professional judgement is required. Monitoring and audit controls determine whether the organisation can detect, investigate and evidence problems.

This workflow perspective is consistent with research emphasising that the organisational value of AI depends on its integration into actual business processes rather than its deployment as a standalone technological capability (Sarkar, 2026; Hughes et al., 2026). For financial institutions, this means that AI governance should be designed around the business outcome and control environment rather than around the model in isolation.

Human judgement remains particularly important where AI influences consequential financial decisions. Research on AI-supported decision-making suggests that decision quality depends on the interaction between human participants and AI systems rather than on AI capability alone (Zercher et al., 2025). The relevant governance question is therefore not simply whether a human remains formally involved, but whether that human has sufficient information, authority and understanding to challenge the system's output and intervene when required.

The increasing autonomy of AI systems makes this issue even more significant. As AI moves from generating recommendations towards executing tasks or coordinating multiple steps within a workflow, governance must increasingly address identity, authority and permissions. Kshetri (2025) highlights the importance of security, identity and oversight as AI systems become more agentic. In financial services, this means that access controls and technical permissions can become direct mechanisms of regulatory control: they determine what an AI system is allowed to access, influence and execute.

AI also introduces a stronger dependency dimension. Wealth-management institutions may rely on external foundation models, cloud platforms, data providers, AI APIs or specialised RegTech services. These dependencies create questions concerning data use, confidentiality, availability, service continuity, model changes, contractual controls and exit options. AI governance therefore intersects with third-party and dependency governance. Organisational resilience research further suggests that resilience needs to be considered across interconnected technological and organisational dependencies rather than at the level of individual systems alone (Neri, Niccolini and Virili, 2026).

Cybersecurity is similarly inseparable from AI governance. AI-enabled financial systems may have access to sensitive client information, proprietary investment data and regulated workflows. Compromise of the underlying model, data pipeline, identity infrastructure or integration layer could therefore affect both confidentiality and the integrity of regulatory controls. AI resilience consequently requires attention to the complete technology environment rather than the model in isolation.

These considerations suggest that AI governance in wealth management should encompass at least four interconnected dimensions. Data governance determines whether the system uses appropriate, accurate and sufficiently controlled information. Model and technology governance addresses performance, validity, explainability, security and change. Workflow governance establishes how AI outputs are incorporated into business processes and where human intervention is required. Organisational governance establishes accountability, decision rights, monitoring and escalation. None of these dimensions is sufficient independently; effective control emerges from their interaction.

This perspective also has implications for IT Product Management. AI-enabled regulatory products cannot be managed simply through conventional feature roadmaps. Product Owners need visibility over model dependencies, data sources, regulatory requirements, user roles, decision rights, monitoring mechanisms and operational risks. Product lifecycle management must therefore include controlled experimentation, testing, deployment, monitoring, retraining or model changes, incident management and eventual retirement. AI governance becomes part of product governance.

The central implication is that AI changes the architecture of compliance because it changes where decisions are made and how they are produced. When AI participates in client profiling, investment recommendations, surveillance or compliance processes, the organisation's control environment must extend across the entire AI-enabled workflow.

Consequently, the appropriate object of governance is not necessarily the AI model itself. It is the AI-enabled financial process: the combination of data, model, technology, workflow, human judgement, permissions, controls and evidence through which a regulated activity is performed. This shift from model governance to process governance provides a more effective basis for managing AI in wealth management because it aligns technological oversight with the actual location of regulatory risk and organisational accountability.

10. Data Governance as the Foundation of Regulatory Technology

Across the regulatory domains examined in this paper, data represents a common technological foundation. Suitability depends on accurate and sufficiently current client information. Advisory compliance depends on reliable client, product and interaction records. Market-abuse surveillance depends on transaction, market and identity data. MiFID II reporting depends on accurate and complete transaction and reference information. FinSA controls depend on client classification, advisory and product information. AI-enabled financial services depend on many of the same data sources, together with additional requirements concerning data provenance, quality and appropriate use.

Data quality is therefore not merely an IT concern. Where regulatory decisions, controls or reports depend on data, weaknesses in that data can become regulatory risk. An incorrect client classification may result in inappropriate controls being applied. An incomplete transaction record may prevent effective surveillance or reporting. An outdated risk profile may contribute to an inappropriate investment recommendation. Consequently, the reliability of a regulatory control depends partly on the reliability of the information on which that control operates.

This creates a fundamental relationship between data governance and regulatory governance. Data governance establishes the structures through which critical information is defined, owned, collected, validated, transformed, accessed, retained and monitored. Regulatory governance establishes what the organisation is required to achieve. Regulatory technology connects the two by embedding regulatory requirements into processes that depend on governed data.

One of the most important requirements is data lineage. An organisation should be able to establish where critical information originated, how it was transformed, which systems processed it and where it was subsequently used. Lineage is particularly important where information passes through multiple applications before contributing to a regulated decision or report. Without adequate lineage, it may be difficult to determine whether an error originated in the source data, a transformation process, an integration layer or the application applying the regulatory rule.

Data quality is equally important. Critical regulatory attributes require appropriate validation, completeness checks, consistency controls and mechanisms for identifying outdated or anomalous information. The required level of quality should also reflect the consequence of error. A data field used to support a consequential investment decision or regulatory report requires stronger controls than information used for a lower-risk operational purpose. This supports a risk-based approach to data governance rather than treating every data element as equally critical.

Data ownership is another essential component. Responsibility for important regulatory data should be clearly assigned, including accountability for definitions, quality, access and remediation. Without clear ownership, data problems can persist between business and technology functions because no party has explicit responsibility for resolving them. Data ownership therefore forms part of the wider accountability structure supporting regulatory controls.

Data consistency is particularly important in complex financial institutions. The same client, product or transaction may be represented across multiple systems, each with different data models, update cycles and ownership arrangements. Contradictory information can lead to inconsistent regulatory outcomes. Effective architecture should therefore establish appropriate master and reference data capabilities, common identifiers and controlled integration mechanisms where these are necessary to maintain consistency.

Data retention also has a regulatory dimension. Records may need to remain available for regulatory, operational, evidential and audit purposes over defined periods. Retention must therefore balance the need for accessibility and reconstruction with requirements concerning privacy, security and appropriate disposal. A record that cannot be retrieved when required may be functionally equivalent to a record that was never captured.

Data security is similarly inseparable from regulatory technology. Wealth-management systems contain sensitive client, financial and investment information, while regulatory platforms may also contain confidential investigations, risk assessments and compliance decisions. Strong identity and access management, segregation of duties, encryption, monitoring and controlled data sharing are therefore not simply cybersecurity measures; they protect the integrity and confidentiality of the regulatory control environment.

The importance of these principles increases significantly when AI is introduced. AI systems may consume data from multiple internal and external sources, combine structured and unstructured information, and transform that information into recommendations, classifications or other outputs. Recent research on AI and investment services identifies data quality and data-related risks as important considerations in the regulatory treatment of AI-enabled financial activities. These concerns reinforce the principle that AI governance cannot be separated from the governance of the data on which AI systems depend.

AI also creates additional data-governance questions. Organisations need to understand what data is used to develop, configure or operate an AI system, whether that data is appropriate for the intended purpose, how sensitive information is handled, and whether outputs can be traced sufficiently to the relevant inputs and system context. Where external AI providers are involved, questions of data access, retention, reuse and confidentiality become particularly important.

The relationship between data and AI therefore extends beyond traditional data quality. Data provenance becomes important because the organisation needs to understand the origin and context of information used by the system. Purpose limitation becomes important because data collected for one regulatory or business purpose may not automatically be appropriate for another. Access control becomes important because AI systems may be capable of combining information that would otherwise remain separated across organisational boundaries. Monitoring becomes important because changes in source data can alter AI behaviour even where the underlying model has not changed.

These considerations support the broader argument that AI governance should be embedded within organisational processes rather than treated solely as model governance (Batool, Zowghi and Bano, 2025; Papagiannidis, Mikalef and Conboy, 2025). Data governance is one of the mechanisms through which this organisational control becomes operational.

Data governance also has an important architectural dimension. In a distributed regulatory environment, data often flows between CRM platforms, client master systems, product repositories, trading platforms, advisory applications, compliance engines, reporting systems and audit repositories. Effective regulatory technology therefore requires not only high-quality individual datasets but also reliable integration, common definitions, controlled transformations and visibility over dependencies.

This means that data architecture is itself part of regulatory architecture. Decisions about master data, integration patterns, identifiers, data models, event histories and storage mechanisms can directly influence the organisation's ability to implement and evidence regulatory controls. Technology architecture should therefore consider regulatory data as a strategic enterprise asset rather than treating it as a by-product of individual applications.

The implications extend to IT Product Management. Product Owners responsible for regulatory capabilities need to understand which data their products depend upon, who owns that data, what quality requirements apply, how it is transformed and what downstream controls rely upon it. A product may appear functionally complete while remaining operationally ineffective if the underlying data dependencies are unreliable. Data quality and lineage should therefore be treated as product requirements where they materially affect regulatory outcomes.

The central principle is that regulatory technology is only as reliable as the data and information architecture supporting it. Data is not simply an input into regulatory processes; in many cases, it determines which regulatory context applies, which control is triggered, what decision is produced and what evidence can subsequently be provided.

Consequently, effective regulatory technology requires a shift from viewing data governance as a supporting IT discipline towards recognising it as a component of regulatory control infrastructure. As financial institutions become increasingly digital and AI-enabled, the ability to govern the provenance, quality, ownership, consistency, security and lifecycle of critical data becomes fundamental to maintaining compliance, accountability and trust.

11. Architecture, Integration and Regulatory Control

The IT implications of regulatory technology extend beyond individual applications. Modern wealth-management environments are typically composed of interconnected platforms and services, including customer relationship management (CRM), client master and portfolio-management systems, market-data providers, order-management systems, compliance engines, document-management platforms, reporting solutions, identity and access-management services, cloud infrastructure and external data providers. Regulatory outcomes are therefore often produced by distributed technology architectures rather than by a single system.

This has an important consequence: regulatory control depends not only on the functionality of individual applications but also on the reliability of the integrations connecting them. A regulatory requirement may appear simple from a business perspective while requiring data and processing capabilities distributed across multiple systems.

For example, the requirement to ensure that only suitable products are recommended may depend on the availability of current client information, risk classification, investment objectives, knowledge and experience, product characteristics and portfolio information. These attributes may originate in different systems and be combined within an advisory or suitability platform. The control is therefore not located solely in the suitability engine; it emerges from the interaction between data sources, integration mechanisms, business rules, workflow and human decision-making.

The same principle applies to market-abuse surveillance. A sophisticated analytical model is of limited value if transaction data is incomplete, delayed, incorrectly mapped or disconnected from relevant client, instrument or market information. Similarly, regulatory reporting can fail even when the reporting application itself is functioning correctly if upstream systems provide incomplete or inconsistent information.

This leads to a fundamental architectural principle:

Regulatory control is only as strong as the weakest critical dependency in the process that implements it.

This principle shifts attention from application functionality towards end-to-end control effectiveness. A technically well-designed application does not necessarily provide an effective regulatory control if one of its critical upstream or downstream dependencies is unreliable. Regulatory technology must therefore be assessed across the complete chain through which information is collected, transformed, processed, acted upon and evidenced.

Integration architecture is consequently a core component of regulatory control. APIs, event streams, databases, message brokers, data pipelines and other integration mechanisms determine how reliably information moves between systems. Integration failures can result in missing data, stale information, duplicated records, inconsistent states or delayed processing. In a regulatory context, these are not merely technical defects; they can affect the organisation's ability to fulfil regulatory obligations.

This also makes dependency visibility an important aspect of Product Management. A Product Owner should understand not only the functionality delivered by a product but also the systems and services required for that functionality to operate. Relevant dependencies may include:

• applications and business services;

• APIs and integration interfaces;

• databases and data platforms;

• client, product and market-data providers;

• identity and access-management systems;

• workflow and case-management platforms;

• AI and machine-learning services;

• cloud infrastructure and platform services; and

• external technology and data vendors.

The significance of these dependencies increases as regulatory processes become more automated. Automation can reduce manual effort and improve consistency, but it can also increase the consequences of an integration failure. A manually performed control may fail visibly when an employee cannot access the required information. An automated control may instead continue processing incomplete information unless the architecture explicitly detects and handles the failure.

This creates a requirement for control-aware integration design. Systems should be capable of identifying missing, delayed or inconsistent information and applying appropriate exception handling rather than silently continuing. Depending on the regulatory significance of the process, this may require validation, reconciliation, alerts, workflow interruption, human review or controlled fallback mechanisms.

Integration also affects auditability. When a regulatory decision depends on data from several systems, the organisation should be able to reconstruct how information travelled through the architecture and contributed to the resulting decision or report. This requires appropriate logging, identifiers, timestamps, data lineage and traceability across system boundaries. Auditability is therefore not simply a feature of the final application; it must be considered across the integrated architecture.

The same principle applies to resilience. Regulatory processes may depend on external market-data services, cloud platforms, AI providers or third-party RegTech solutions. A disruption in one dependency can affect the availability or integrity of the overall control. Neri, Niccolini and Virili (2026) emphasise the importance of understanding organisational cyber resilience across interconnected technological and organisational dependencies. Regulatory architecture should therefore consider not only whether individual components are secure and available but whether the end-to-end regulatory process remains controllable when dependencies fail.

Third-party technology introduces additional considerations. External vendors may provide market data, cloud infrastructure, AI capabilities, screening services or regulatory technology. The organisation remains responsible for the regulatory outcome even where part of the technology stack is externally provided. Consequently, vendor governance becomes part of regulatory technology governance, including assessment of service availability, data handling, security, change management, incident response, auditability and exit arrangements.

AI further increases architectural complexity. AI capabilities may be consumed through external APIs, embedded within enterprise applications or operated as shared services across multiple workflows. This creates dependencies not only on the availability of the AI service but also on model versions, configuration, data access, permissions and provider behaviour. Kshetri (2025) highlights the growing importance of identity, authority and oversight as AI systems become more capable and autonomous. These concerns need to be reflected in the architecture through controlled permissions, clearly defined decision boundaries and appropriate monitoring.

Architecture therefore becomes a mechanism through which regulatory accountability is operationalised. Identity systems determine who or what is authorised to perform an action. Integration mechanisms determine which information is available to a decision. Workflow systems determine when approvals or interventions occur. Logging determines what can subsequently be demonstrated. Resilience mechanisms determine whether controls continue to operate when dependencies fail.

This perspective also changes the role of the Product Owner. Product ownership in a regulatory environment cannot be limited to defining features and prioritising a backlog. The Product Owner needs to understand the control architecture surrounding the product: its regulatory objectives, data dependencies, integrations, decision points, failure modes, external services and evidence requirements. Prioritisation should therefore consider architectural dependencies and control risk alongside user value and delivery capacity.

RegTech consequently becomes an enterprise-architecture issue rather than simply an application-development issue. Effective regulatory technology requires coordinated design across applications, data, integration, identity, infrastructure, workflows, AI services and third-party providers. The objective is not merely to build compliant applications, but to create an integrated technology environment in which regulatory controls remain reliable, observable, resilient and accountable across the complete business process.

The central principle is therefore that regulatory control is an end-to-end architectural property. Compliance cannot be guaranteed by the sophistication of an individual application when the outcome depends on multiple interconnected systems. As wealth management becomes increasingly digital and AI-enabled, the ability to understand, govern and continuously monitor these dependencies becomes a core capability of both technology management and regulatory compliance.

12. Human Oversight and Accountability

A recurring theme across suitability, advisory compliance, market-abuse surveillance and AI-enabled financial services is the relationship between automation and human judgement. Automation can increase consistency, processing speed and scalability, but it does not automatically transfer regulatory accountability from the organisation to the technology. In regulated financial services, responsibility for the outcomes produced by technology remains embedded within the governance structures of the regulated organisation.

This distinction becomes particularly important when AI systems generate recommendations, classifications, alerts or other decision-support outputs. An AI model may identify an unusual trading pattern, but the organisation must determine how that alert is investigated and what action follows. An AI system may recommend an investment strategy, but the bank remains responsible for ensuring that the advisory process satisfies applicable suitability, disclosure and conduct requirements. Similarly, an algorithm may classify a client according to a particular risk profile, but the organisation must establish whether the underlying data, methodology and resulting classification are appropriate.

AI therefore changes how decisions are supported, rather than eliminating the need for organisational accountability. Azzutti (2026) argues that the increasing use of AI in financial services exposes limitations in treating technological change as irrelevant to regulatory governance. The technology used to perform a regulated activity may change substantially while the underlying regulatory responsibility remains with the regulated entity.

This creates an important distinction between a human-in-the-loop and meaningful human oversight. The presence of a human somewhere in a workflow does not necessarily provide effective control. If an employee receives an AI-generated recommendation without sufficient information to assess it, lacks authority to override it, or is operationally discouraged from challenging it, human involvement may be largely symbolic. Effective oversight requires the human decision-maker to have the information, authority, time and contextual understanding necessary to exercise independent judgement.

Research on human-AI decision-making reinforces this point. Zercher et al. (2025) demonstrate that the interaction between human teams and generative AI can affect decision-making processes and decision quality. The relevant design question is therefore not simply whether a human reviews an AI output, but whether the overall process enables the human to identify, question and appropriately act upon potentially incorrect or inappropriate outputs.

Human oversight should consequently be designed into the technology architecture rather than added as a procedural control after implementation. Depending on the risk and consequence of the decision, this can include:

• escalation thresholds;

• approval and review workflows;

• exception management;

• override and intervention capabilities;

• explanations or supporting evidence;

• decision and rationale records;

• role-based access controls;

• segregation of duties;

• monitoring of human and automated decisions; and

• clearly assigned accountability for outcomes.

These mechanisms create explicit decision rights between technology and human actors. A low-risk automated classification may require monitoring but no individual approval for every transaction. A consequential investment recommendation may require qualified human review before execution. A market-surveillance alert may be automatically prioritised while the decision to escalate an investigation remains with an authorised investigator. The appropriate allocation depends on the potential consequences, degree of automation, reliability of the technology and ability to detect and correct errors.

Market-abuse surveillance provides a useful example. Mazzarisi et al. (2024) present machine learning as a mechanism for supporting the detection of potentially suspicious trading activity rather than as an autonomous determination that market abuse has occurred. The system can identify patterns that would be difficult to detect manually, prioritise cases and provide analytical evidence, while investigators retain responsibility for interpreting the circumstances and determining appropriate action.

This model can be described as decision augmentation rather than decision replacement. The objective of automation is to improve the capacity of human decision-makers by processing larger volumes of information, identifying relevant patterns and presenting evidence in a structured manner. Human judgement remains important where contextual interpretation, professional responsibility or regulatory discretion is required.

However, human oversight can itself introduce risks. One such risk is automation bias, where users place excessive confidence in system-generated recommendations or alerts. If an AI system is perceived as authoritative, human reviewers may approve its outputs without sufficient challenge. Effective oversight therefore requires not only an override function but also appropriate information, training, interface design and organisational incentives that encourage challenge when necessary.

The design of the user interface can consequently become part of the control environment. A system that displays an AI recommendation without showing relevant data, confidence indicators, exceptions or supporting evidence may encourage passive acceptance. Conversely, a system that clearly presents the basis for a recommendation, highlights missing information and requires explicit confirmation for consequential decisions can support more effective human judgement.

This is particularly relevant to suitability and advisory compliance. An advisory system may automatically generate a recommendation based on client objectives, risk tolerance, knowledge and experience, product characteristics and portfolio information. The adviser should nevertheless be able to understand the relevant inputs, identify material limitations, challenge the recommendation and document the rationale for accepting or overriding it. The technology therefore needs to support the adviser as a regulated decision-maker rather than merely automate the advisory process.

The same principle applies to client risk classification. An automated model may identify a risk profile based on available client information, but the organisation should be able to establish how that classification was generated, whether the underlying information remains current and what should happen when the result conflicts with other relevant evidence. Human intervention should be possible where circumstances warrant it, with the resulting decision appropriately recorded.

AI-enabled processes therefore require a clear allocation of responsibilities across human actors, automated systems and organisational governance. The system should establish what the technology may decide, what it may recommend, what actions it may initiate and where human approval is mandatory. These boundaries become particularly important as AI systems become more autonomous. Kshetri (2025) highlights the importance of identity, authority and oversight as AI capabilities develop. In practical terms, an AI system should not simply have technical access to perform an action; its permissions should reflect explicitly defined business and regulatory authority.

This also creates requirements for auditability. Where a regulated decision involves both automated processing and human judgement, the organisation should be able to reconstruct the interaction between them. Relevant evidence may include the data available at the time, the AI output, the applicable rules or model version, the human review, any override or modification, the final decision and the identity of the responsible individual. Such records provide a basis for demonstrating that human oversight was substantive rather than merely procedural.

From a Product Management perspective, this means that requirements for regulated products should include decision rights and accountability requirements, not merely functional requirements. A Product Owner should ask: What can the system decide? What can it recommend? What must a human approve? Under what circumstances must the workflow escalate? Who has authority to override the system? What evidence must be retained? What happens when required information is missing or the system is unavailable?

These questions transform human oversight from a policy statement into an implementable technology capability. Approval workflows, exception handling, permissions, audit trails and intervention mechanisms become concrete product and architecture requirements.

The broader principle is that automation does not eliminate accountability; it changes where accountability must be exercised and how it must be evidenced. Effective financial technology should therefore be designed to augment professional judgement while preserving meaningful human control over consequential regulated decisions.

The objective is not necessarily to minimise human involvement. Rather, it is to allocate human and automated capabilities deliberately: allowing technology to perform high-volume analytical and processing tasks while ensuring that consequential decisions remain subject to appropriate judgement, authority and accountability. In this sense, effective AI and regulatory technology should not be measured solely by the amount of manual work eliminated, but by whether the resulting process is more consistent, more transparent, more controllable and more effectively accountable.

13. Implications for IT Product Management

The convergence of regulation and technology changes the role of the IT Product Owner in financial services. In a conventional digital product environment, Product Management is often centred on understanding user needs, defining value, prioritising features and delivering an effective customer or employee experience. In regulated financial services, these responsibilities remain important but are insufficient on their own.

The traditional Product Owner may ask:

What does the user need?

The Product Owner of a regulatory technology capability must additionally ask:

What must the organisation be able to control, demonstrate and evidence?

This distinction is significant because a regulatory product is not successful merely because its users can complete a process efficiently. It must also enable the organisation to satisfy its regulatory obligations, manage associated risks and demonstrate that relevant controls operated effectively. Product value therefore includes control effectiveness, auditability, resilience and regulatory adaptability, alongside user and business value.

This creates at least six interconnected dimensions of regulatory Product Ownership.

Regulatory interpretation

The first responsibility is translating regulatory and compliance requirements into actionable product requirements. Legislation and regulatory guidance are generally expressed in legal, principles-based or business terms rather than as technical specifications. The Product Owner therefore needs to understand the regulatory objective and translate it into appropriate data, business rules, workflow, permissions, controls and evidence.

This does not mean that the Product Owner replaces Legal or Compliance expertise. Rather, the role provides the bridge between regulatory interpretation and technical implementation. Ambiguous requirements need to be challenged and clarified, while dependencies and implementation consequences need to be understood before they become technical debt or control weaknesses.

Data requirements

The second dimension concerns data. As established in Section 10, regulatory controls depend on the availability, quality, provenance and appropriate use of critical information. Product requirements should therefore identify which data is required, where it originates, who owns it, how its quality is validated and how it is transformed or consumed.

Data should be treated as part of the product's control design rather than merely as an implementation dependency. Where an incorrect or incomplete data attribute could affect a regulated decision, its quality requirements become part of the product's risk profile.

Workflow design

The third dimension is workflow. Regulatory obligations are generally implemented through business processes rather than isolated technical functions. The Product Owner therefore needs to determine where controls should occur, which activities require approval, where exceptions should be raised and how responsibilities are allocated across business and technology roles.

For example, suitability may require a sequence involving client-data collection, profiling, product assessment, recommendation, human review and evidence capture. Market-abuse surveillance may involve data ingestion, analytical detection, alert prioritisation, investigation and case closure. The product should support the complete control process rather than optimising only one individual step.

This reinforces the importance of workflow integration identified by Sarkar (2026) and Hughes et al. (2026). Technology creates value when it becomes integrated into the organisational process through which decisions and outcomes are produced.

Automation and human judgement

The fourth dimension concerns the allocation of work between automated systems and human decision-makers. Product Owners need to identify which activities can be automated safely, which require human review and where intervention must be mandatory.

This becomes increasingly important with AI. A system may be capable of generating recommendations, classifications or prioritised alerts without necessarily being appropriate to make the final decision. As discussed in Section 12, meaningful human oversight requires clearly defined decision rights, intervention mechanisms and accountability. Kshetri (2025) highlights the importance of identity, authority and oversight as AI systems become more capable and autonomous.

Product requirements should therefore specify not only what an automated system can do, but also what it is permitted to do. This distinction between technical capability and authorised capability is particularly important in regulated environments.

Monitoring and control effectiveness

The fifth dimension is monitoring. Implementing a control is not sufficient; the organisation also needs to know whether the control continues to operate as intended.

Monitoring may include data-quality indicators, exception volumes, model performance, alert outcomes, processing failures, user overrides, control breaches and operational resilience measures. The appropriate metrics depend on the product and regulatory outcome, but the underlying principle is consistent: regulatory controls require ongoing observation.

This is particularly important for AI-enabled products because model performance, input data and usage patterns can change over time. A product that was effective when deployed may become less reliable as data, models, configurations, regulations or business processes change. AI governance research therefore emphasises ongoing organisational and process-level governance rather than relying solely on initial model approval (Batool, Zowghi and Bano, 2025; Papagiannidis, Mikalef and Conboy, 2025).

Evidence and auditability

The sixth dimension is evidence. Regulated organisations must often be able to demonstrate not only the outcome of a process but how that outcome was reached. Product design should therefore consider the evidence required to reconstruct decisions, exceptions, approvals and control outcomes.

This may include the relevant client and product data, applicable rules, system or model versions, timestamps, user identities, recommendations, overrides, approvals and subsequent actions. Evidence requirements should be defined at the product-design stage rather than added retrospectively when an audit or regulatory review occurs.

This leads to a broader conception of the Product Owner's responsibility. The product lifecycle needs to account not only for discovery, development and deployment but also for control operation, monitoring, regulatory change, incidents, remediation and eventual retirement. Regulatory products are therefore living organisational capabilities rather than static software implementations.

The prioritisation model also changes. Conventional product management often weighs customer value, commercial value, effort and strategic alignment. Regulatory Product Management must additionally consider regulatory urgency, control effectiveness, risk reduction, audit findings, data quality, architectural dependencies, operational resilience and regulatory change. A feature with limited visible user value may nevertheless be strategically important because it closes a material control gap.

This creates a more comprehensive definition of product value. A regulatory product can create value by reducing manual effort, improving user experience and increasing operational efficiency, but it can also create value by reducing regulatory risk, improving consistency, strengthening evidence and increasing the organisation's ability to respond to regulatory change.

RegTech therefore requires Product Owners to manage trade-offs between business value, regulatory risk and technology complexity. These trade-offs are particularly important where competing priorities exist. A regulatory enhancement may need to take precedence over a more visible user feature because failure to implement it could create material regulatory or operational exposure. Conversely, excessive controls can create unnecessary complexity and reduce usability. Effective Product Management therefore requires proportionate control rather than simply maximising the number of controls.

The role also becomes increasingly cross-functional. Regulatory products sit at the intersection of Compliance, Legal, Risk, business operations, data management, architecture, cybersecurity, engineering and senior management. The Product Owner must create shared understanding across these groups and make dependencies, risks, decisions and trade-offs transparent.

This is particularly important for AI-enabled products. AI introduces dependencies that may extend beyond conventional application ownership, including model providers, training or retrieval data, cloud services, model configuration, identity and access controls, monitoring capabilities and third-party contracts. Product ownership must therefore extend beyond the application's functional boundary to the broader ecosystem required to operate the capability safely.

The result is a different conception of Product Ownership from conventional digital product management. The product is not merely delivering functionality to users. It is delivering a controlled organisational capability.

Such a capability combines technology, data, business processes, human judgement, governance and evidence to achieve a defined business and regulatory outcome. The Product Owner's responsibility is therefore not simply to ensure that software works, but to ensure that the overall capability remains fit for purpose, controlled, observable, adaptable and accountable.

This perspective also provides a practical definition of successful regulatory Product Management: the organisation should be able to explain what the product is intended to control, which data and systems it depends upon, who is accountable for decisions, how exceptions are handled, how effectiveness is monitored and what evidence demonstrates that the control operated as intended.

The central principle is therefore:

In regulated financial services, the Product Owner does not merely manage a product; they manage the technology-enabled capability through which the organisation fulfils, controls and evidences a business and regulatory obligation.

This represents the convergence of Product Management, technology architecture and regulatory governance. As financial institutions become increasingly digital and AI-enabled, the ability to manage these dimensions as an integrated product capability becomes an increasingly important source of both regulatory resilience and organisational value.

14. From Compliance Applications to Organisational Control

The preceding analysis points towards a broader interpretation of compliance technology. RegTech should not be understood simply as a mechanism for automating compliance activities or reducing the cost of regulatory processes. Rather, it represents an increasing integration of regulatory requirements with the data, architecture, workflows and decision mechanisms through which financial institutions operate.

Charoenwong et al. (2024) demonstrate that technology investment driven by compliance requirements can have consequences beyond the immediate compliance function, including effects on operational capabilities and market structure. This suggests that regulatory technology should not be evaluated solely in terms of whether it reduces compliance effort. Compliance-driven technology investment can create capabilities that influence how the wider organisation operates.

This is particularly evident where regulatory technology capabilities are reused across multiple organisational processes. Client identification and classification capabilities may support onboarding, risk management, fraud prevention and advisory processes. Identity and access-management capabilities may support regulatory segregation of duties as well as broader cybersecurity and operational resilience. Transaction data collected for regulatory reporting may also support surveillance, analytics and risk management.

RegTech can therefore become part of the organisational infrastructure through which the institution operates and exercises control.

The same development is visible in investment management and advisory services. Mertzanis (2025) identifies applications of AI across portfolio optimisation, forecasting, risk management, robo-advisory and regulatory compliance. As these technologies become embedded within business processes, the distinction between a "compliance system" and a "business system" becomes increasingly difficult to maintain. The same technology may simultaneously support a commercial objective and implement a regulatory control.

This leads to a broader proposition: IT architecture is increasingly part of the control environment of a financial institution.

A well-designed technology environment can perform or support multiple control functions. It can:

• prevent inappropriate actions;

• enforce regulatory and business rules;

• restrict access according to defined authority;

• identify anomalies and potential risks;

• require human approval for consequential activities;

• record decisions and interventions;

• generate regulatory and audit evidence;

• monitor control outcomes and exceptions; and

• support regulatory reporting and management information.

These capabilities demonstrate that technology does not merely facilitate organisational control. It can instantiate control within the operating environment.

For example, access controls can prevent unauthorised users from performing restricted activities. Workflow rules can prevent an investment process from proceeding until required information or approval has been obtained. Suitability controls can prevent or flag recommendations that do not satisfy defined conditions. Surveillance systems can identify transactions requiring investigation. Audit logging can create evidence of how a decision was made. In each case, the technical design contributes directly to the organisation's ability to control behaviour.

This changes the meaning of "control" in a digital organisation. Traditional controls may have relied heavily on policies, procedures and periodic human review. Digital controls increasingly operate continuously through data validation, automated rules, workflow constraints, permissions, monitoring and exception handling. The organisation's control environment is therefore partly expressed through its technology architecture.

This does not imply that technology can replace governance. On the contrary, embedding controls within technology increases the importance of sound governance because technical controls reflect decisions about what is permitted, prohibited, escalated or automatically executed. A poorly designed automated control can apply an incorrect rule consistently and at scale. The effectiveness of digital control therefore depends on the quality of the underlying regulatory interpretation, data, architecture and governance.

AI intensifies this relationship. AI systems increasingly participate in activities that were previously performed primarily by human professionals, including information analysis, client profiling, investment recommendations, risk assessment, anomaly detection and compliance monitoring (Mertzanis, 2025). As AI becomes integrated into these workflows, it can move from being a passive analytical tool towards becoming an active component of organisational decision-making.

This creates a fundamental distinction between automation of tasks and automation of organisational authority. Automating a low-risk analytical task may require relatively limited controls. Allowing an AI system to initiate a consequential action requires much stronger governance because the system is no longer merely producing information; it is participating in the exercise of organisational authority.

The more technology can recommend, decide or act, the more important it becomes to establish explicit boundaries around that authority. Identity, permissions, workflow constraints, approval requirements, monitoring and intervention mechanisms become critical components of the control environment. Kshetri (2025) highlights the importance of identity, security and oversight as AI systems become increasingly autonomous.

This suggests that AI governance should not focus exclusively on whether an AI model is accurate or compliant in isolation. The relevant question is also what the AI-enabled system is permitted to do within the organisation. A highly accurate model may still create unacceptable risk if it has excessive permissions, insufficient monitoring or the ability to initiate actions outside its intended authority.

The appropriate governance object is therefore increasingly the AI-enabled organisational process rather than the model alone. Such a process may include client and market data, an AI model, business rules, workflow orchestration, human decisions, identity and access controls, external services and audit records. Control effectiveness emerges from the interaction of all these components.

This perspective also has implications for organisational accountability. When technology becomes part of the mechanism through which an institution exercises control, responsibility cannot be delegated simply because an automated system performed the relevant action. The organisation must remain able to understand the system's role, define its authority, monitor its operation and intervene when necessary.

Consequently, regulatory technology should be evaluated according to whether it enables the organisation to remain in control of its technology-enabled processes. This includes the ability to prevent inappropriate actions, detect failures, understand decisions, intervene when necessary, recover from incidents and demonstrate what occurred.

The concept of organisational control therefore provides a useful bridge between RegTech, enterprise architecture and AI governance. Compliance is no longer implemented solely through policies that sit above technology. Increasingly, regulatory requirements are translated into the architecture itself: into data models, permissions, business rules, workflows, monitoring mechanisms, decision rights and evidence.

The resulting organisational capability is broader than a collection of compliance applications. It is a technology-enabled control environment in which regulation, business processes, data, technology and human accountability are interconnected.

The central proposition is therefore that financial institutions should move from thinking about compliance applications towards thinking about organisational control capabilities. The objective is not simply to build systems that perform compliance tasks, but to design an environment in which regulatory obligations are consistently translated into controlled actions, observable outcomes and demonstrable evidence.

As AI systems become increasingly capable of recommending, deciding and acting, this distinction becomes even more important. The strategic question is no longer simply whether technology can perform a regulated task. It is whether the organisation can remain accountable, controllable and resilient while technology performs that task at increasing scale and autonomy.

15. Conclusion

The analysis in this paper demonstrates that the relationship between financial regulation and information technology has fundamentally changed. Regulation can no longer be considered solely a legal or compliance concern that technology subsequently implements. In increasingly digital financial institutions, regulatory obligations are translated directly into data structures, applications, workflows, business rules, permissions, analytical models, monitoring mechanisms and evidence. Technology has therefore become part of the environment through which regulatory obligations are operationalised and controlled.

The examination of wealth management illustrates this convergence particularly clearly. Suitability depends on the quality and availability of client and product information. Advisory compliance increasingly operates through digitally supported workflows and decision systems. Market-abuse surveillance depends on integrated transaction and market data and increasingly sophisticated analytical techniques. MiFID II and FinSA requirements are implemented across distributed systems rather than through isolated regulatory applications. Across these domains, the regulatory outcome depends on the interaction between legal requirements, business processes, data, technology and human judgement.

This leads to the central conclusion of the paper: regulatory control is increasingly an information-architecture and organisational-control problem.

Data governance forms the foundation of this control environment. Regulatory decisions and reports depend on accurate, complete, consistent and appropriately governed information. Data lineage, ownership, quality, retention and security are therefore not merely technical disciplines; they contribute directly to regulatory control effectiveness. Where incorrect or incomplete data can result in an inappropriate recommendation, missed surveillance signal or inaccurate regulatory report, data quality becomes a form of regulatory risk.

Architecture and integration extend this principle across the enterprise. Regulatory controls increasingly depend on multiple interconnected applications, APIs, databases, data providers, identity systems, cloud services and external vendors. The effectiveness of an individual application cannot therefore be considered in isolation. A sophisticated suitability engine cannot compensate for defective client data, and an advanced surveillance model cannot compensate for incomplete or delayed transaction information. Regulatory control is consequently an end-to-end architectural property, dependent on the reliability and governance of the complete process.

Human oversight remains an essential component of this architecture. Automation can improve scalability, consistency and analytical capability, but it does not remove organisational accountability. AI-generated recommendations, classifications and alerts require appropriate decision rights, escalation mechanisms, intervention capabilities and evidence. Meaningful human oversight requires more than placing an employee at the end of an automated workflow; the individual must have sufficient information, authority and understanding to challenge the system and intervene when necessary.

Artificial intelligence makes these considerations more significant. AI is increasingly being applied across investment management, advisory services, risk management and compliance (Mertzanis, 2025). As AI systems become more capable, the relevant governance question shifts from whether a model is accurate towards what the AI-enabled process is permitted to do. Identity, access, authority, workflow boundaries, monitoring and intervention become increasingly important as systems move from generating information towards recommending, deciding and acting.

This suggests that AI governance should extend beyond model governance. The appropriate unit of governance is increasingly the AI-enabled organisational process, incorporating data, models, applications, workflows, human judgement, permissions, external dependencies and evidence. Governance must therefore be proportionate to the sensitivity of the data, significance of the decision, degree of autonomy and potential consequences of failure. This is consistent with the broader literature emphasising organisational context, human oversight and responsible AI governance (Batool, Zowghi and Bano, 2025; Papagiannidis, Mikalef and Conboy, 2025).

The analysis also changes how RegTech should be understood. RegTech is not simply a collection of applications designed to reduce compliance costs. Technology-driven compliance investment can create broader organisational capabilities and affect operational processes beyond the immediate compliance function (Charoenwong et al., 2024). Regulatory capabilities such as identity management, client data, transaction monitoring, workflow controls and auditability can become reusable organisational infrastructure. Compliance technology can therefore contribute to operational efficiency, risk management, resilience and digital transformation.

This has direct implications for IT Product Management. The Product Owner in a regulated financial institution must look beyond conventional questions of user needs, features and delivery. The relevant questions include: What regulatory outcome must the organisation achieve? What data is required? Where should the control operate? What can be automated? Where is human judgement required? Which systems and third parties does the control depend upon? How is effectiveness monitored? What evidence must be retained? What happens when the technology or a dependency fails?

Product ownership therefore becomes the management of a controlled organisational capability rather than simply the delivery of software functionality. Product success includes user value and operational efficiency, but also control effectiveness, auditability, resilience, regulatory adaptability and accountability. This requires close collaboration between Product Management, Compliance, Risk, Legal, Architecture, Data, Cybersecurity, Engineering and business stakeholders.

The broader implication is that financial institutions should move from thinking in terms of isolated compliance applications towards thinking in terms of organisational control capabilities. Regulatory obligations are increasingly embedded within the architecture of the organisation itself. Data models determine what information is available; permissions determine who or what may act; workflows determine where intervention occurs; algorithms determine how information is analysed; monitoring determines whether controls continue to operate; and auditability determines whether the organisation can demonstrate what happened.

This does not mean that technology replaces regulation, Compliance or human judgement. Rather, it means that effective compliance increasingly depends on the quality of the socio-technical system through which regulatory requirements are implemented. The strongest control environment is therefore not necessarily the one with the most automation or the most sophisticated AI, but the one in which responsibilities are clear, technology operates within defined boundaries, critical dependencies are understood, human intervention remains meaningful and outcomes can be demonstrated.

The central conclusion can therefore be expressed as follows:

The evolution of financial regulatory technology is a shift from using IT to support compliance towards using IT as part of the organisation's control architecture.

As AI and automation continue to increase the scale and autonomy of technology-enabled decision-making, this shift will become more important. The strategic challenge for financial institutions is not simply to adopt more capable technology, but to ensure that increased technological capability is matched by appropriate control, accountability and resilience.

Ultimately, the question is no longer whether technology can perform regulated activities. It is whether the organisation can remain accountable, controllable and resilient while technology performs them.

References

Azzutti, A. (2026) ‘AI governance after MiFID II: beyond (mere) technological neutrality?’, ERA Forum, 27, pp. 7–31.

Charoenwong, B., Kowaleski, Z.T., Kwan, A. and Sutherland, A.G. (2024) ‘RegTech: Technology-driven compliance and its effects on profitability, operations, and market structure’, Journal of Financial Economics, 154, 103792. doi: 10.1016/j.jfineco.2024.103792

El Khoury, R., Alshater, M.M. and Joshipura, M. (2025) ‘RegTech advancements—a comprehensive review of its evolution, challenges, and implications for financial regulation and compliance’, Journal of Financial Reporting and Accounting, 23(4), pp. 1450–1485. doi: 10.1108/JFRA-05-2024-0286.

Gaspar, R.M. and Oliveira, M. (2024) ‘Robo Advising and Investor Profiling’, FinTech, 3(1), pp. 102–115. doi: 10.3390/fintech3010007.

Hughes, L., Davies, F., Li, K., Madugoda Gunaratnege, S., Malik, T. and Dwivedi, Y.K. (2026) ‘Beyond the hype: Organisational adoption of Generative AI through the lens of the TOE framework–A mixed methods perspective’, International Journal of Information Management, 86, 102982. doi: 10.1016/j.ijinfomgt.2025.102982

Kshetri, N. (2025) ‘Governing Agentic AI: Security, Identity, and Oversight in the Age of Autonomous Intelligent Systems’, Computer, 58(8), pp. 123–129. doi: 10.1109/MC.2025.3572173.

Mazzarisi, P., Ravagnani, A., Deriu, P., Lillo, F., Medda, F. and Russo, A. (2024) ‘A machine learning approach to support decision in insider trading detection’, EPJ Data Science, 13, 66. (

Mertzanis, C. (2025) ‘Artificial intelligence and investment management: Structure, strategy, and governance’, International Review of Financial Analysis, 107, 104599. doi: 10.1016/j.irfa.2025.104599.

Papagiannidis, E., Mikalef, P. and Conboy, K. (2025) ‘Responsible artificial intelligence governance: A review and research framework’, The Journal of Strategic Information Systems, 34(2), 101885. doi: 10.1016/j.jsis.2024.101885.

Scherer, B. and Lehner, S. (2025) ‘What drives robo-advice?’, Journal of Empirical Finance, 80, 101574. doi: 10.1016/j.jempfin.2024.101574.

van der Woude, M., et al. (2022) ‘Implementation of MiFID II investor protection provisions by private banks within the European Union’, Journal of Financial Regulation and Compliance, 31(1), pp. 1–15. doi: 10.1108/JFRC-10-2021-0087.

Zercher, D., Jussupow, E., Benke, I. and Heinzl, A. (2025) ‘How Can Teams Benefit From AI Team Members? Exploring the Effect of Generative AI on Decision-Making Processes and Decision Quality in Team–AI Collaboration’, Journal of Organizational Behavior, pp. 1–28. doi: 10.1002/job.2898.

Contact

Reach out via email for inquiries.

Email

Subscribe to newsletter

info@grcadvisory.ch

© 2025. All rights reserved.