Skip to main content
Oversight Institute
Category: Regulatory Frameworks

Regulatory Technical Standards

Also known as:
Simply put

Regulatory Technical Standards (RTS) are detailed technical rules developed within the European Union's financial services regulatory framework to specify how broader legislation should be applied in practice. They translate high-level legal mandates into specific methods, definitions, and requirements, such as how to define a market or calculate certain capital requirements. In the banking sector, they are typically drafted by the European Banking Authority (EBA) before being adopted into EU law.

Formal definition

Regulatory Technical Standards (RTS) are a category of EU financial services technical standards that elaborate the detailed technical elements of underlying EU legislative acts, distinct from Implementing Technical Standards (ITS) which address uniform conditions of application. Within the banking domain, the EBA prepares final draft RTS pursuant to specific legislative mandates, for example, defining the term 'market' for calculating the general component of market risk, specifying methods for identifying the main risk driver of a position, or detailing the scope and methodology for prudential consolidation of investment firms. Based on the evidence provided, RTS are developed as final draft standards by the EBA (illustrated by mandates tied to phase 2 of the EBA's roadmap for implementing the EU Banking Package on market access) and are jurisdiction-specific to the EU regulatory regime; they should not be assumed to carry equivalent authority or applicability in other jurisdictions. The evidence does not establish the full adoption procedure beyond the EBA's drafting role, so the subsequent endorsement and legal-force steps are not detailed here.

Why it matters

For institutions operating within the EU financial services regime, Regulatory Technical Standards (RTS) determine the precise methods by which broad legislative mandates become operational requirements. Because RTS specify technical details, such as how the term 'market' is defined for calculating the general component of market risk, how the main risk driver of a position is identified, or how prudential consolidation and its capital requirements are handled, they directly shape how regulated firms measure exposures and structure compliance. Ambiguity at the legislative level is resolved at the RTS level, which is why professionals tracking regulatory obligations often watch RTS development as closely as the underlying acts.

Who it's relevant to

Compliance and regulatory affairs teams in EU-regulated banks
These teams rely on RTS to understand precisely how legislative mandates translate into operational requirements, such as definitions and methodologies for market risk or prudential consolidation. Tracking EBA final draft RTS helps them anticipate obligations, though they should confirm the current adoption and effective status of any given standard rather than treating a published draft as binding.
Risk measurement and prudential reporting functions
Functions responsible for calculating capital requirements and measuring exposures depend on RTS for the technical definitions and methods they must apply, for example, defining the term 'market' for the general component of market risk or identifying the main risk driver of a position. Consistency with the applicable RTS is central to defensible risk calculations.
Third-party and vendor risk managers supporting regulated activities
Where RTS-driven obligations affect functions that are outsourced or supported by external service providers, vendor risk teams may need to obtain corresponding data, controls, or assurances from those providers. Understanding which requirements originate in RTS helps these teams scope diligence appropriately, while recognising that EU-specific RTS may not apply to providers or relationships outside the EU regime.
Legal and policy specialists tracking EU financial services rulemaking
Specialists advising on EU financial services must distinguish RTS from Implementing Technical Standards (ITS) and situate each within the relevant legislative programme, such as the EBA's roadmap for the EU Banking Package. They should note that the full endorsement pathway conferring legal force involves steps beyond the EBA's drafting role that the standard itself does not, on its own, complete.

Inside RTS

Detailed technical specifications
RTS set out granular, technical requirements that operationalize higher-level obligations established in primary legislation, translating broad legal principles into specific implementable rules. They are intended to supplement rather than replace the underlying legislative text.
Delegated status
RTS are typically a form of delegated or secondary legislation, developed under a mandate from primary legislation. They derive their authority from that empowering instrument and do not create obligations beyond the scope of that delegation.
Scope of application
RTS specify which entities, activities, or arrangements they govern. In a third-party and supply chain context, this often includes expectations around outsourcing, service provider oversight, and contractual arrangements, though the precise coverage depends on the mandate and sector.
Supervisory and compliance expectations
RTS commonly articulate what supervised entities must do to demonstrate compliance, which may include documentation, risk assessment, and monitoring expectations for third-party relationships, without themselves conferring any certification or safe-harbor guarantee.
Jurisdictional boundaries
RTS apply within the regulatory regime and jurisdiction that issues them. Their requirements are not automatically applicable across other regions or sectors, and equivalent expectations elsewhere may differ in substance and form.

Common questions

Answers to the questions practitioners most commonly ask about RTS.

Are Regulatory Technical Standards the same as the underlying legislation they support?
No. RTS are typically a form of secondary or delegated measure that add technical detail to primary legislation; they do not replace or override the parent law. The primary legislation sets the mandate and scope, while the RTS specify how particular requirements are to be applied in practice. Treating an RTS as the source of the obligation, rather than as the technical elaboration of an obligation established elsewhere, misreads the relationship. The distinction matters when interpreting the legal basis and limits of a given technical requirement.
Does complying with an RTS mean an organization is fully compliant with the broader regulatory regime?
Not necessarily. An RTS typically addresses specific technical aspects of a broader framework and does not encompass the full set of obligations that framework imposes. Meeting the detailed requirements of one RTS does not confer overall compliance, nor does it substitute for obligations set out in the primary legislation, other technical standards, or accompanying guidance. Compliance with an RTS should be understood as satisfying a defined component, not as a certification of end-to-end conformance with the regime as a whole.
How does an RTS typically influence third-party and supply chain risk management programs?
Where an RTS specifies technical requirements relevant to outsourcing, ICT service providers, or supplier arrangements, it can shape how programs define controls, contractual terms, and monitoring expectations for in-scope relationships. In many programs, teams map the applicable technical requirements to their due diligence and ongoing oversight processes. The extent of influence depends on whether the RTS applies to the organization's sector and jurisdiction, and on which third-party relationships fall within its defined scope.
How should a program determine which of its third parties fall within the scope of a given RTS?
Scope is typically defined by the parent legislation and refined by the RTS itself, often by reference to the type of service, the criticality of the function, or the sector of the regulated entity. Programs commonly assess each relationship against those scoping criteria rather than applying the standard uniformly across all vendors. Because scope boundaries vary by regime and sector, it is important to confirm what the specific RTS covers and what it explicitly excludes before applying its requirements to a supplier population.
Should an RTS's technical requirements be embedded in contracts or handled through separate assurance processes?
Practices vary depending on the risk tier and the nature of the requirement. In many programs, requirements that can be expressed as obligations, such as data handling, subcontracting conditions, or audit and access rights, are reflected in contractual clauses, while others are addressed through assurance activities such as assessments or evidence review. Contractual inclusion and independent assurance serve different purposes: a contractual commitment is not the same as verified performance, so programs often use both rather than relying on one alone.
How does the jurisdictional nature of an RTS affect its use in a global supplier program?
An RTS is generally tied to a specific regulatory regime and jurisdiction, so its requirements are not automatically applicable to suppliers or entities outside that scope. Global programs typically need to identify which relationships are subject to the RTS by virtue of the regulated entity's location or the service provided, rather than applying it across the entire supplier base. Requirements under one regime should not be presumed equivalent to those of another; mapping across jurisdictions requires attention to where each standard applies and where it does not.

Common misconceptions

RTS are the same as the primary legislation they support.
RTS are typically delegated or secondary instruments that operationalize obligations set in primary legislation. They supplement and specify those obligations rather than establishing them, and cannot extend beyond the mandate that empowers them.
Complying with the technical specifications in RTS provides a guarantee or certification of compliance.
RTS set out expectations that supervised entities are generally expected to meet, but adherence is subject to supervisory judgment and does not confer certification or a safe harbor. Demonstrating compliance typically still requires evidence, documentation, and ongoing oversight.
RTS requirements apply globally to any organization managing third parties.
RTS are jurisdiction- and sector-specific. Their applicability is limited to the regulatory regime that issues them, and organizations operating across regions may face different or additional expectations elsewhere.

Best practices

Trace each RTS requirement back to the primary legislation and mandate it operationalizes, so you understand its scope and cannot mistake supplementary technical detail for the underlying legal obligation.
Confirm whether a given RTS applies to your entity, activities, and jurisdiction before treating its expectations as binding, and identify where different regional or sectoral regimes impose divergent requirements.
Map RTS expectations relating to outsourcing and third-party arrangements against your existing TPRM controls, documenting where coverage is complete and where gaps remain.
Maintain evidence and documentation that demonstrate how third-party oversight practices meet RTS expectations, recognizing that adherence is subject to supervisory judgment rather than self-certification.
Treat RTS-driven controls as ongoing obligations by embedding them into continuous monitoring and periodic review, rather than treating a one-time implementation as sufficient.
Coordinate legal, compliance, and procurement functions when interpreting RTS, since technical specifications often carry implications for contractual arrangements with service providers and suppliers.
Application Security Isn’t Optional Anymore.