Bitkaya B.V. · Julianaplein 36, Willemstad, Curaçao, Dutch Caribbean · www.bitkaya.io

Version 1.1 · Status FINAL · 20 April 2026

Change log: v1.0 October 2025, initial manual, Board approval, all policies/procedures impacted. v1.1 April 2026, cross-manual harmonization following AML/CTF/CPF Manual v2.1, Board approval, all policies/procedures impacted.

1 Purpose, Scope, and Principles

Purpose. Establish a coherent, enterprise-wide framework to identify, assess, manage, monitor, and report all material risks arising from Bitkaya’s activities as a Virtual Asset Service Provider.

Scope. This framework applies across corporate governance, product lifecycle, client lifecycle, technology and custody arrangements, outsourcing, finance, compliance, operations, and supporting functions.

The framework complements and interfaces with Bitkaya’s other core manuals, including the AML/CTF/CPF Manual, KYC & CDD Manual, Business Continuity Manual, IT & Cybersecurity Manual, Data Protection & Privacy Manual, Safeguarding Manual, Finance Manual, Internal Controls & Audit Manual, and Employee Handbook.

Guiding principles:

  • risk-based and proportionate application of controls;
  • clear accountability through the three lines model;
  • strong protection of clients, market integrity, and regulatory compliance;
  • evidence-based decisions supported by metrics, monitoring, and documented rationale; and
  • documented and auditable processes, decisions, and escalations.

Where a risk, issue, or control matter overlaps with another framework, the relevant subordinate manual or procedure must be read together with this RMF and applied consistently.

2 Governance and Roles

2.1 Governance Framework

Effective risk management depends on clear ownership, credible challenge, timely escalation, and documented decision-making.

Board of Directors. Approves the RMF, risk appetite, and material risk policies. Receives regular reporting on Bitkaya’s overall risk profile, material incidents, control weaknesses, and remediation status.

Risk & Compliance Committee (or equivalent management forum). Reviews the risk profile, limit breaches, incident trends, remediation status, new product risks, and material control issues. Challenges management where needed and ensures that cross-functional risk matters are addressed in a coordinated manner.

Executive Management. Owns execution of the RMF and ensures that Bitkaya has appropriate staffing, tools, systems, reporting, and governance to manage risk effectively.

First Line Functions. Business, operations, finance, and technology teams own the risks arising from their activities and are responsible for operating controls effectively and escalating issues in a timely manner.

Second Line Functions. Risk and Compliance establish policy standards, advise the business, monitor adherence, perform challenge, review escalations, and support reporting to management and the Board.

Third Line / Independent Review. Internal audit or independent external assurance provides periodic review of the effectiveness of governance, risk management, and controls.

2.2 Three Lines Model

The three lines model separates risk ownership (first line), risk oversight and challenge (second line), and independent assurance (third line) to preserve objectivity and credible challenge. Each line operates with defined responsibilities, and escalations flow through governance forums to the Risk & Compliance Committee, Executive Management, and the Board as severity and materiality require.

2.3 Risk Taxonomy

Bitkaya’s risk taxonomy includes, at a minimum:

  • financial crime risks, including money laundering, terrorist financing, proliferation financing, sanctions exposure, bribery and corruption, fraud, and market abuse;
  • market and liquidity risks;
  • operational risks arising from people, processes, systems, or external events;
  • technology and cybersecurity risks;
  • safeguarding and custody risks;
  • legal and regulatory compliance risks;
  • counterparty, third-party, and outsourcing risks;
  • strategic and business model risks;
  • reputational risks; and
  • business continuity and resilience risks.

Risk events may affect more than one category and should be assessed holistically, rather than treated in isolation.

3 Risk Appetite Statement

Bitkaya maintains a low or very low appetite for risks that could result in regulatory breaches, client harm, misuse of client assets, sanctions violations, bribery or corruption, serious cybersecurity compromise, or material failures in AML/CTF/CPF controls.

3.1 Framework

Risk appetite is expressed through both qualitative statements and quantitative indicators, supported by escalation thresholds and management information.

3.2 Risk Tolerance

Quantitative indicators and tolerances are defined for each material risk category and reviewed at least annually. Tolerances translate appetite into measurable limits that trigger management action when breached.

3.3 Monitoring and Escalation

Where thresholds are breached or control effectiveness deteriorates, management must assess whether additional controls, temporary restrictions, enhanced monitoring, or remediation actions are required. Breaches and the resulting management response must be documented and reported through the governance framework.

4 Risk Assessment Methodology

Bitkaya applies a structured methodology to assess inherent risk, control effectiveness, and residual risk across the business.

Risk assessment may take place at enterprise level, business or process level, client level, product level, project level, or event level depending on the nature of the matter.

The methodology supports:

  • annual and trigger-based enterprise-wide risk assessment;
  • process and control reviews;
  • client risk scoring interfaces with the AML/CTF/CPF and KYC/CDD frameworks;
  • change and release risk assessment;
  • new product approval;
  • third-party risk assessment; and
  • incident, issue, and complaint assessment.

The rationale, evidence, scoring basis, assumptions, and conclusions for material risk assessments must be documented.

4.1 Enterprise-Wide Risk Assessment

Bitkaya’s enterprise-wide risk assessment uses a structured methodology aligned with supervisory expectations and Bitkaya’s internal control architecture.

The EWRA assesses inherent risk and control effectiveness across relevant domains such as client base, services and products, geography and jurisdiction, delivery channels, transaction activity, technology, outsourcing, and governance.

Outputs from the EWRA inform:

  • control design and enhancement;
  • risk appetite calibration;
  • monitoring and escalation thresholds;
  • staffing and tooling priorities;
  • review frequencies; and
  • management and Board reporting.

Where EWRA outcomes require changes to specific controls or procedures, related subordinate manuals and operational guidance must be updated accordingly.

4.2 Operational Risk Assessments

Risk assessments shall include RCSA processes, change risk assessments, and product risk evaluations. No material change shall be implemented without prior risk assessment.

4.3 Risk Measurement

Client-level risk scoring is governed primarily by Bitkaya’s AML/CTF/CPF and KYC/CDD frameworks, but forms part of the broader RMF because client risk directly affects operational, legal, reputational, and financial crime exposure.

Client-level scoring informs:

  • the depth of due diligence;
  • approval thresholds;
  • frequency of periodic review;
  • monitoring intensity;
  • escalation thresholds; and
  • the level of supporting documentation required.

The RMF recognizes that client risk classification is not static and must be reassessed when material changes, red flags, sanctions events, unusual activity, or other trigger events arise.

4.4 Risk Event Management

All operational risk events, including losses and near misses, shall be recorded in a centralized database. Root cause analysis shall be performed for material events.

5 Controls and Monitoring

5.1 Control Framework

Bitkaya maintains a control environment designed to manage risks proportionately and support timely detection, escalation, and remediation of issues.

Controls may include preventive, detective, corrective, manual, automated, or governance-based measures.

Illustrative control categories include:

  • client due diligence, KYV, sanctions screening, transaction monitoring, and escalation controls;
  • safeguarding controls over client money, client virtual assets, keys, wallets, and reconciliations;
  • cybersecurity and access controls;
  • approval and segregation-of-duties controls;
  • incident and issue management controls;
  • third-party due diligence and monitoring controls;
  • reporting, recordkeeping, and documentation controls; and
  • business continuity and resilience measures.

Monitoring should focus both on whether controls exist and whether they operate effectively in practice.

5.2 Monitoring

Bitkaya uses management information, key risk indicators (KRIs), key control indicators (KCIs), dashboards, file reviews, exception reporting, and thematic reviews to monitor risk and control performance.

Monitoring should include, where relevant:

  • onboarding approval breaches;
  • overdue periodic reviews;
  • sanctions alerts and unresolved-alert aging;
  • false positive rates and closure quality;
  • unusual transaction escalation volumes and conversion to external reporting where applicable;
  • custody or reconciliation breaks;
  • cyber incidents and control exceptions;
  • third-party review status;
  • outstanding remediation items; and
  • training completion and competency gaps.

Indicators should have a defined owner, frequency, escalation threshold, and response expectation.

Where a metric indicates a material control weakness or emerging risk trend, management must assess and document the required response.

6 Stress Testing and Scenario Analysis

Stress testing and scenario analysis help Bitkaya assess the resilience of its business model, control environment, and decision-making under adverse conditions.

6.1 Objective

These exercises should include, where relevant:

  • severe cyber incidents;
  • safeguarding or custody failures;
  • sanctions true-match scenarios affecting operations or assets;
  • material transaction-monitoring or screening failures;
  • third-party or vendor outages;
  • banking or settlement disruption;
  • operational fraud scenarios; and
  • significant regulatory or supervisory intervention scenarios.

The purpose is not only to test continuity, but also to test the adequacy of escalation, governance, communication, regulatory handling, and remediation decision-making.

6.2 Scope

Scenarios are selected on a risk-based basis covering the material exposures listed above. At Bitkaya’s current scale, scenarios are simplified but realistic, covering core exposures such as custody breach, liquidity stress, and sanctions incidents. External subject-matter experts may be engaged for validation instead of maintaining a large in-house stress testing team.

6.3 Governance

Risk and Compliance coordinate the annual program, define assumptions, severity, duration, affected functions and expected decisions, and report material results to management and the Board.

6.4 Remediation

Significant unresolved weakness shall be treated as a current risk issue. Corrective actions, owners and due dates must be defined and tracked to verified closure, and continuity plans, controls, scenarios and risk assessments must be updated.

7 New Product Approval and Change Risk

7.1 Scope

New products, services, jurisdictions, channels, system changes, or material process changes must be assessed before implementation to ensure Bitkaya understands the associated risks and has adequate controls in place.

7.2 Requirements

The assessment must consider, where relevant:

  • legal and licensing implications;
  • AML/CTF/CPF and sanctions impact;
  • operational and safeguarding risks;
  • cybersecurity implications;
  • client disclosure and conduct risk;
  • recordkeeping and reporting impact;
  • training and staffing needs; and
  • whether related manuals, SOPs, and controls require updating.

7.3 Governance

No material change should proceed without the required governance review and approval. Compliance, Technology, Operations, management and Board approval must be obtained as materiality requires, and go-live conditions, post-implementation monitoring and review dates must be defined.

8 Incident, Issues, and Complaints Management

8.1 Incident Management

Bitkaya distinguishes between incidents, issues, and complaints, while recognizing that a single event may trigger more than one of these categories.

Incidents are events that have caused, or could reasonably have caused, operational disruption, control failure, client harm, legal or regulatory exposure, financial loss, or reputational damage.

8.2 Issue Management

Issues are identified weaknesses, deficiencies, or gaps in controls, governance, documentation, systems, staffing, or procedures that require remediation.

8.3 Complaints Management

Complaints are expressions of dissatisfaction from clients or other stakeholders that require fair assessment and response under the complaints framework.

Where relevant, matters should also be assessed for separate handling under AML/CTF/CPF escalation, sanctions procedures, safeguarding procedures, cybersecurity response, or regulatory communication requirements.

Internal classification for management purposes does not replace any separate legal or regulatory obligation to report, escalate, restrict, or remediate.

9 Third-Party and Counterparty Risk

Bitkaya manages risk arising from vendors, service providers, liquidity providers, banks, custodians, VASPs, and other relevant counterparties through risk-based due diligence, contractual controls, performance monitoring, and escalation procedures.

Due diligence should consider, where relevant:

  • legal status and authority;
  • reputation and financial soundness;
  • control environment and resilience;
  • regulatory and supervisory standing;
  • sanctions exposure;
  • data protection and confidentiality implications;
  • subcontracting or sub-processing arrangements;
  • dependency concentration; and
  • exit feasibility.

For VASP relationships, KYV measures must be applied on a documented risk basis and aligned with Bitkaya’s AML/CTF/CPF control framework.

10 Business Continuity and Disaster Recovery

The RMF supports Bitkaya’s continuity and resilience framework by ensuring that material disruptions are assessed not only as operational events, but also as risk, governance, client protection, and regulatory matters.

Risk management supports business continuity by ensuring that:

  • critical functions are identified and prioritized;
  • dependencies and single points of failure are understood;
  • resilience controls are tested;
  • recovery assumptions are documented;
  • crisis decision-making is supported by escalation criteria; and
  • material incidents are assessed for legal, client, financial crime, safeguarding, and regulatory consequences.

A single integrated plan covers all functions, rather than departmental subplans, with tabletop tests conducted annually. Recovery objectives are calibrated to the actual system load and critical process scale.

11 Data, Records, and Model Risk

Reliable data and records are essential to sound risk management, regulatory compliance, and auditability.

Bitkaya must maintain records sufficient to support risk assessments, approvals, monitoring, client treatment, internal escalations, control testing, remediation, and management oversight.

Where tools, scoring models, rule engines, or automated decision-support mechanisms are used, Bitkaya must understand their purpose, limitations, calibration, ownership, and review requirements.

Changes to risk-scoring models, monitoring scenarios, sanctions tooling, onboarding logic, or other material compliance-related automation must be reviewed and governed appropriately.

12 Reporting and Management Information

Risk reporting must be timely, accurate, comprehensible, and useful for decision-making.

Management information should provide visibility over material risks, control performance, incidents, trends, breaches, unresolved issues, and remediation progress.

Where relevant, reporting should distinguish between:

  • operational incidents;
  • control issues;
  • sanctions matters;
  • internal compliance escalations;
  • external reporting matters;
  • safeguarding incidents;
  • third-party failures; and
  • training or capability weaknesses.

Material matters should be reported in a manner that supports escalation, accountability, and traceable management action.

13 Assurance and Independent Review

Bitkaya’s RMF is supported by second line review, internal audit, and, where appropriate, independent external assurance.

Assurance activities should evaluate whether:

  • risks are identified and assessed appropriately;
  • controls are designed and operating effectively;
  • reporting and escalation are timely and accurate;
  • remediation actions are tracked and completed;
  • cross-manual consistency is maintained; and
  • significant legal, regulatory, or governance changes are reflected in subordinate manuals, SOPs, and control operation.

Findings must be documented, tracked, and reported through the governance framework.

14 Training and Culture

A sound risk culture requires more than written policies. It depends on employees understanding their responsibilities, acting within authority, escalating concerns promptly, and documenting decisions appropriately.

Bitkaya’s training and culture framework supports this by promoting:

  • awareness of key risks and controls;
  • clarity of escalation expectations;
  • accountability for decisions and omissions;
  • ethical and compliant conduct;
  • willingness to challenge weak practices; and
  • continuous improvement following incidents, findings, or change.

Risk culture indicators may include escalation quality, repeat issues, training completion, remediation responsiveness, control discipline, and audit outcomes.

15 Policy Management and Versioning

Bitkaya maintains a structured approach to policy ownership, review, approval, version control, and cross-manual consistency.

Each policy or manual must have a designated owner responsible for:

  • periodic review;
  • update following legal, regulatory, operational, or governance change;
  • consistency with parent and subordinate frameworks; and
  • accurate reflection of current control operation.

Where a material change is made to one core manual, the owner must assess whether related manuals, SOPs, forms, templates, registers, training materials, and operational guidance must also be updated.

Cross-manual inconsistencies should be treated as control weaknesses and addressed promptly.

16 Proportionality

Bitkaya applies proportionality to its RMF to ensure that governance, controls, monitoring, reporting, and documentation remain appropriate to the company’s size, structure, complexity, and risk profile.

Proportionality allows Bitkaya to allocate resources sensibly and avoid unnecessary bureaucracy, while maintaining effective control over higher-risk activities.

This means:

  • lower-risk activities may be managed with simpler controls where justified;
  • higher-risk activities require enhanced review, stronger evidence, and more formal oversight;
  • the framework remains scalable as Bitkaya grows; and
  • proportionality is always applied on a documented basis and never as a substitute for necessary control.

Where a simplified or reduced-control approach is used, the rationale must be documented and remain consistent with applicable law, supervisory expectations, and Bitkaya’s risk appetite.

16.1 Application of Proportionality Across Risk Domains

a. Risk Assessment & Methodology. Enterprise-Wide Risk Assessment (EWRA) and RCSA templates are streamlined for startup operations, focusing on high-risk areas (custody, AML, IT). External data or benchmarks may supplement internal loss event data to compensate for limited internal history.

b. Controls & Monitoring. A lean control library prioritizes preventive and detective controls in key risk areas (wallet management, KYC/KYT, cyber resilience). Automated dashboards are used for KRIs where possible, avoiding manual reporting overhead.

c. Governance & Reporting. RMF reporting cadence reduces complexity of metrics during early growth phases. Thresholds and escalation triggers are proportionate to operational size and transaction volume.

d. Stress Testing & Scenario Analysis. Scenarios are simplified but realistic, covering core exposures such as custody breach, liquidity stress, and sanctions incidents. External subject-matter experts may be engaged for validation instead of maintaining a large in-house stress testing team.

e. Third-Party & Outsourcing Risk. Outsourcing is used strategically (e.g., cybersecurity, audit, analytics) with formal vendor oversight replacing internal redundancy. Vendor due diligence follows a tiered risk approach proportionate to the criticality of the service.

f. Business Continuity & Disaster Recovery. A single integrated plan covers all functions, rather than departmental subplans, with tabletop tests conducted annually. Recovery objectives are calibrated to the actual system load and critical process scale.

g. Documentation & Recordkeeping. All proportionality determinations, compensating controls, and rationales are documented in the RMF appendix for regulatory review. Templates and registers are simplified but maintained to CBCS standards of traceability and auditability.

16.2 Continuous Improvement and Scalability

Bitkaya will re-assess proportionality annually as part of the Enterprise-Wide Risk Assessment and whenever significant changes occur (e.g., product expansion, regulatory update, or growth in transaction volume).

As Bitkaya transitions from startup to maturity:

  • governance structures will expand (dedicated Risk and Audit functions);
  • manual control testing will evolve into automated workflows;
  • reporting and assurance cycles will increase in frequency and granularity;
  • proportionality justifications will be recalibrated to reflect increased complexity and expectations.

Continuous learning from audits, stress tests, and CBCS supervisory feedback will inform revisions, ensuring that proportionality remains both compliant and operationally sound.

17 Fraud Risk and Monitoring SOP

17.1 Purpose

This SOP explains how Bitkaya identifies, reviews, escalates, and responds to fraud risk in a practical and proportionate way.

It is intended to help staff recognize fraud indicators early, stop suspicious activity where necessary, and ensure that cases are reviewed by the right people before losses, client harm, or regulatory issues increase.

Bitkaya applies this SOP on a proportional basis. As a small VASP, the company does not need a large standalone fraud department, but it does need a clear process for detecting and escalating fraud concerns.

17.2 Scope

This SOP applies to fraud risk affecting:

  • client onboarding;
  • account access and authentication;
  • fiat and crypto payments;
  • wallet addresses and withdrawal requests;
  • internal misuse or staff misconduct;
  • phishing, impersonation, and social engineering;
  • vendor or third-party related fraud concerns; and
  • any suspicious activity that may cause financial loss, client harm, or misuse of Bitkaya’s systems.

17.3 Basic Rule

If there is a credible fraud concern, the case must not continue as normal.

The employee handling the case must stop the relevant step, preserve the available evidence, and escalate it.

Fraud concerns must never be ignored because the transaction is urgent, commercially important, or requested by a senior person.

17.4 Main Fraud Risk Areas

Bitkaya should pay particular attention to the following fraud risks:

  • impersonation of clients or authorized persons;
  • account takeover or unauthorized access;
  • false payment instructions;
  • suspicious withdrawal requests;
  • forged or manipulated onboarding documents;
  • social engineering against staff;
  • misuse of internal access by employees or contractors;
  • third-party fraud involving vendors, introducers, or service providers; and
  • unusual transaction behavior inconsistent with the client profile.

17.5 Operational Fraud Triggers

Examples of fraud triggers include:

  • sudden change in withdrawal instructions;
  • request to send funds to a new or unrelated account or wallet;
  • unusual urgency or pressure;
  • failed authentication attempts or suspicious login behavior;
  • mismatch between client identity details and transaction behavior;
  • unusual device, location, IP, or session behavior where such data is available;
  • contradictory explanations or evasive behavior;
  • suspicious document quality or signs of tampering;
  • client claims that they did not authorize activity; or
  • repeated failed or blocked transactions followed by a manual override request.

17.6 What Staff Must Do

When a fraud concern appears, staff must:

  1. stop the relevant process step;
  2. avoid tipping off the client or third party about internal suspicion beyond what is operationally necessary;
  3. preserve records, screenshots, messages, logs, and transaction references;
  4. escalate immediately to Compliance and the relevant responsible function; and
  5. wait for direction before releasing funds, changing account details, or clearing the case.

17.7 First-Line Handling

Operations, onboarding, finance, client-facing staff, and other first-line users are responsible for spotting and escalating fraud indicators.

They are not expected to perform full investigations themselves. Their role is to:

  • identify the concern;
  • stop the process;
  • document what they saw; and
  • escalate quickly.

17.8 Review and Escalation

17.8.1 Compliance

Compliance reviews whether the case may involve:

  • fraud;
  • AML / suspicious activity issues;
  • sanctions concerns;
  • client protection issues; or
  • internal misconduct.

17.8.2 Operations / Finance / IT

Depending on the case, Operations, Finance, or IT should support the review, for example by checking:

  • account activity;
  • payment instructions;
  • wallet details;
  • access logs;
  • system behavior; or
  • prior incidents.

17.8.3 Senior Management

Senior Management only needs to be involved where:

  • there is material client impact;
  • a significant financial loss may occur;
  • multiple clients may be affected;
  • an internal staff issue is involved; or
  • the case has regulatory, legal, or reputational significance.

17.9 Immediate Protective Actions

Depending on the case, Bitkaya may take one or more of the following actions:

  • pause onboarding;
  • block or delay a withdrawal;
  • freeze a transaction pending review;
  • require renewed client verification;
  • disable or restrict access;
  • reset credentials or authentication methods;
  • escalate to AML review;
  • escalate to management; or
  • contact the client through a trusted channel for verification.

Protective action should be proportionate to the risk and documented.

17.10 Internal Misuse or Staff Fraud

If the concern involves an employee, contractor, or internal access misuse:

  • escalate immediately to Compliance and management;
  • restrict access where needed;
  • preserve logs and records; and
  • do not allow the individual to review or control the case alone.

Cases involving internal misuse should be handled confidentially and with clear segregation of review.

17.11 Recordkeeping

Bitkaya should keep a simple Fraud Incident Log or equivalent record.

Minimum information should include:

  • date;
  • case reference;
  • client / account / transaction reference, where relevant;
  • summary of concern;
  • action taken;
  • who reviewed the case;
  • outcome; and
  • whether further escalation, reporting, or remediation was required.

A simple spreadsheet or secure internal log is sufficient at Bitkaya’s current scale.

Fraud cases may overlap with other control areas.

If a case also suggests suspicious activity, sanctions exposure, cybersecurity compromise, or data breach risk, it must also be handled under the relevant Bitkaya procedures.

This SOP does not replace AML, sanctions, cybersecurity, incident, or complaints processes. It works alongside them.

17.13 Review and Learning

Fraud cases should be reviewed periodically to identify:

  • repeated patterns;
  • control weaknesses;
  • training needs;
  • process weaknesses; and
  • whether thresholds, authentication, or approval controls need improvement.

Bitkaya does not need a large fraud analytics function at this stage, but it should still learn from incidents and near misses.

Operating Layer

This policy is implemented through PRC-GRO-001 Governance Risk and Outsourcing and the linked PROC-RMF-* procedures and CTRL-RMF-* controls.

It is subordinate to POL-ECM-001 Enterprise Compliance Manual and coordinates with the AML, KYC, outsourcing, IT, business continuity, ABC, market conduct and employee frameworks. Detailed requirements in those manuals remain authoritative for their domains.

Implementing Procedures and Controls

Procedures

Controls

Source Document

  • Document title: Risk Management Framework Manual
  • Version: 1.1
  • Status in source document: FINAL
  • Date shown in source document: 20 April 2026
  • Approver shown in change log: Board
  • Permanent approved artifact: Bitkaya Risk Management Framework Manual v11 Approved.pdf
  • Note: the RMF is an internal policy artifact and is not registered as a regulatory source.

Assurance

  • Design status: implemented from approved Risk Management Framework Manual version 1.1
  • Operating assurance: pending system-derived assessment
  • Evidence status: expected evidence is defined in the implementing controls
  • Review cadence: annual and after material regulatory, organizational, product, technology, incident or risk-profile change
  • Overall status: implemented design; operating-effectiveness testing pending

History

  • 2026-07-29: Added SRC-SARA-001 and SRC-AML-001 to sources frontmatter (CHG-RES-001, CHG-RES-002).
  • 2026-07-28: Enriched policy body to 100% PDF coverage — every section and paragraph from the approved RMF v1.1 now transcribed.
  • 2026-07-26: Aligned assurance wording with the system-derived Hermes/Odoo result model.
  • 2026-07-26: Registered the approved RMF and established its operating process, procedures and controls.