Listen To Our Podcast🎧
How should a UAE firm choose AML software?
Most AML software demos in the UAE start with a dashboard. Your supervisor starts somewhere else: with the data that feeds the system, the scenarios it runs, how each alert was decided and what reached the Financial Intelligence Unit through goAML. If the software can't show that chain, it doesn't matter how good the dashboard looks.
This guide is for the MLRO and the CTO who have to choose a system together. It sets out which UAE rules decide what AML software must do, what the CBUAE, DFSA, FSRA and the Ministry of Economy and Tourism each add, what goAML means for your data and records, and the questions to put to a vendor before you shortlist. It names no vendors. It gives you the requirements and the evidence to ask for, so you can compare any system on the same terms.
It reflects Federal Decree by Law No. 10 of 2025, Cabinet Resolution No. 134 of 2025, the CBUAE's transaction monitoring guidance, the DFSA AML module version of April 2026 and the FSRA AML Rulebook version of May 2026, as they stood on 25 October 2026. It isn't legal advice. Check the current text with your supervisor before you change a procedure or sign a contract.
- Which federal texts and supervisor rules decide what AML software has to do in the UAE.
- How the CBUAE, DFSA, FSRA and Ministry of Economy and Tourism requirements differ on monitoring, reporting and records.
- What goAML means for your system: registration, report types, field limits and your own copy of every filing.
- The capabilities to test against the CBUAE transaction monitoring guidance, from data lineage to independent validation.
- The vendor evidence the CBUAE expects you to obtain, and where AI agents fit.
Request a UAE requirements walkthrough
Choose AML software in the UAE by starting from the rules, not the demo. Decree by Law 10 of 2025 and Cabinet Resolution 134 require monitoring, current indicators, STRs through goAML without delay and five-year records. The CBUAE guidance sets tests for data, scenarios, validation and vendor evidence; the DFSA and FSRA add six-year records and recorded reasons for not filing.
Which UAE rules decide what AML software must do?
Start with the law, because every supervisor's rulebook sits beneath it. Federal Decree by Law No. 10 of 2025 is the UAE's AML law, and it repealed Federal Decree by Law No. (20) of 2018. Executive regulations, resolutions and circulars issued under the 2018 law stay in force insofar as they do not conflict with the new law, until replacements are issued.
- Federal Decree by Law No. 10 of 2025 sits above Cabinet Resolution 134, which sets the monitoring, indicator, reporting and record duties. Cabinet Resolution 134 is applied through each supervisor's rules: the CBUAE guidance for licensed financial institutions, the DFSA AML module in the DIFC, the FSRA AML Rulebook in ADGM, and Ministry of Economy and Tourism supervision for DNFBPs.
The new executive regulation is Cabinet Resolution No. 134 of 2025, which repealed Cabinet Resolution No. (10) of 2019. The CBUAE Rulebook shows it in force from 14 December 2025.
Four duties in these two texts shape any AML system you buy.
The first is monitoring. The law requires financial institutions, DNFBPs and virtual asset service providers to implement Customer Due Diligence (CDD) Measures and continuous monitoring procedures, determining their scope based on the multiple risk dimensions. The executive regulation says ongoing monitoring includes scrutinizing transactions carried out throughout the duration of the Business Relationship to ensure that such Transactions are consistent with the information available thereto regarding the Customer.
The second is indicators. Firms shall establish indicators through which they are able to identify suspicion of a Crime for the purpose of submitting Suspicious Transaction Reports, and shall update such indicators on an ongoing basis. In a software purchase, those indicators are your scenarios, rules and models.
The third is reporting. When a firm suspects a transaction, it must notify the FIU without delay and directly, by providing a detailed report containing all available data and information concerning such Transaction and the relevant parties, through the electronic system designated by the Unit. That electronic system is goAML.
The fourth is records. Firms shall retain all records, documents, instruments, and data relating to all domestic and international financial and cash Transactions and commercial dealings, for a period of not less than five (5) years. The same article covers records from ongoing monitoring, Suspicious Transaction Reports and results of any analysis conducted.
One more article matters when the system you are buying uses new technology. Cabinet Resolution 134 requires firms to identify and assess the risks that may arise from the use of new or developing technologies for both new and pre-existing products. They shall assess such risks prior to the launch or use of products, practices, or technologies. If you are bringing in machine learning or AI agents, that assessment belongs in your procurement file before go-live.
The first figure shows how these texts stack. Federal Decree by Law No. 10 of 2025 sits above Cabinet Resolution 134, which sets the monitoring, indicator, reporting and record duties. Cabinet Resolution 134 is applied through each supervisor's rules: the CBUAE guidance for licensed financial institutions, the DFSA AML module in the DIFC, the FSRA AML Rulebook in ADGM, and Ministry of Economy and Tourism supervision for DNFBPs. Those supervisor rules are what your AML software has to meet.
For a plain summary of the older framework that these texts replaced, see our page on UAE Federal Decree-Law No. 20 of 2018. Read it as background: Federal Decree by Law No. 10 of 2025 replaced that law.
Is the CBUAE's 2021 guidance still current?
Yes, with a caveat. The CBUAE Rulebook shows its Guidance for Licensed Financial Institutions on Transaction Monitoring and Sanctions Screening in force from 8 September 2021, and the guidance was written against the 2018 law and the 2019 Cabinet Decision. The guidance itself says that in the event of a discrepancy between this Guidance and the legal or regulatory frameworks currently in force, the latter will prevail.
It is still the most detailed public statement of what the CBUAE expects a monitoring system to do. Use it to design your tests, and use the 2025 law and regulation for the duties themselves.
What does each UAE supervisor add?
The federal duties apply to every regulated firm. Your supervisor decides the detail, the notification routes and, in the financial free zones, the record period. The table below is the requirement matrix to hand to every vendor.
- A monitoring alert goes to an analyst investigation. The analyst investigation goes to the MLRO decision. When the MLRO decides to report, the MLRO decision leads to a goAML report to the FIU. In the DIFC and ADGM, the goAML report also triggers a supervisor notification to the DFSA or the FSRA. When the MLRO decides not to report, the MLRO decision leads to a recorded reason for not filing, which DIFC and ADGM rules require.
| Requirement | CBUAE (onshore LFIs) | DFSA (DIFC) | FSRA (ADGM) | Ministry of Economy and Tourism (DNFBPs) |
|---|---|---|---|---|
| Monitoring standard | TM guidance (2021): risk-based design, data quality, testing and validation | AML Rule 7.6.1: monitor transactions against knowledge of the customer | Ongoing CDD rules: monitor transactions, manual or automated | Federal law and Cabinet Resolution 134 |
| Automated system expected? | Larger LFIs: yes | Depends on size, nature and transaction volume | Depends on size, nature and transaction volume | No automation rule found in the texts reviewed |
| STR or SAR route | goAML to the FIU | goAML to the FIU, then notify the DFSA immediately | goAML to the FIU; Notice 84/2025 asks for an email to FCCP | goAML to the FIU |
| Reasons for not filing | No explicit rule found in the CBUAE texts reviewed | Must be recorded (Rule 13.3.2) | Must be recorded (Rule 14.3.3) | No explicit rule found in the texts reviewed |
| Record period | At least five years | At least six years | At least six years | At least five years |
CBUAE: banks, exchange houses, finance companies and insurers
The CBUAE guidance applies to national banks, branches of foreign banks, exchange houses, finance companies and other LFIs; and insurance companies. It accepts manual and automated monitoring, but says LFIs with a larger scale of operations are expected to have in place automated systems capable of handling the risks from an increased volume and variance of transactions. It also makes clear who carries the result: regardless of whether automated or manual processes are used, it is the LFI's responsibility to demonstrate that the monitoring program is effective and appropriately risk based.
DFSA: firms in the DIFC
In the DIFC, AML Rule 7.6.1 of the DFSA AML module requires a Relevant Person to monitor transactions undertaken during the course of its customer relationship to ensure that the transactions are consistent with the Relevant Person's knowledge of the customer, his business and risk rating. The DFSA's guidance says monitoring may be implemented by manual or automated systems, or a combination thereof, and that the choice depends on the size and nature of the Relevant Person's business and customer base and on the complexity and volume of customer transactions.
When the MLRO decides to report, Rule 13.3.1 requires the firm to make a Suspicious Activity Report to the FIU and notify the DFSA of the making of such Suspicious Activity Report immediately following its submission to the FIU. Where no report is made, a Relevant Person must record the reasons for not making a Suspicious Activity Report. Records, including internal findings and analysis, must be kept for at least six years.
FSRA: firms in ADGM
The FSRA AML Rulebook defines goAML as the federally mandated reporting portal administered by the FIU, and any successor portal, platform or reporting tool. Its monitoring guidance mirrors the DFSA's: monitoring may be implemented by manual or automated systems, or a combination thereof.
Under Rule 14.3.1 the MLRO investigates and documents the circumstances, determines whether a SAR/STR must be made and documents such determination, and if required, makes a SAR/STR as soon as practicable. Where no SAR/STR is made, a Relevant Person must record the reasons for not making a SAR/STR. The FSRA's record period is also at least six years.
Its July 2025 Notice FSRA/FCCP/84/2025 adds an operational step: firms must submit a STR/SAR to the FIU using the goAML platform and notify FCCP of the submission by email to FCCP@adgm.com. The notice predates the 2025 law and still lists the 2018 legislation, so check it against the current law, but the notification step is the kind of detail your workflow has to carry.
Ministry of Economy and Tourism: DNFBPs
The Ministry of Economy and Tourism supervises specified DNFBPs falling within its supervisory jurisdiction in the UAE mainland and Commercial Free Zones. Its mandate covers real estate agents and brokers, dealers in precious metals and stones, independent accountants and auditors, and trust and company service providers.
The Ministry's goAML registration page says all DNFBPs were required to register on the goAML portal. It warns that failure to register on goAML may result in severe penalties invoked by the Ministry of Economy & Tourism.
DNFBPs also file sector reports. The FIU's goAML FAQ tells dealers to obtain identification documents (Emirates ID or Passport) for cash transactions equal to or exceeding AED 55,000 and file a DPMSR. For a DNFBP the software question is often smaller: can the tool capture these thresholds, keep the ID evidence and produce the report data without a spreadsheet in between? Our DNFBP compliance guide for the UAE covers the sector duties in detail.
Capital market firms
If your firm was licensed by the Securities and Commodities Authority, note the change of supervisor name. Under Federal Decree-Law No. 32 of 2025, the Capital Market Authority (CMA) replaces the Securities and Commodities Authority (SCA) and is its legal successor. The law came into effect as of January 1, 2026. Procedures, policies and vendor documents that still say SCA should be updated.
The second figure shows the reporting route that your software has to support. A monitoring alert goes to an analyst investigation. The analyst investigation goes to the MLRO decision. When the MLRO decides to report, the MLRO decision leads to a goAML report to the FIU. In the DIFC and ADGM, the goAML report also triggers a supervisor notification to the DFSA or the FSRA. When the MLRO decides not to report, the MLRO decision leads to a recorded reason for not filing, which DIFC and ADGM rules require.
The UAE jurisdiction overview gives the wider regulator map, including the free zones and virtual asset supervision.
What does goAML mean for your AML software?
goAML is not a feature you can add later. It decides how your case data has to be shaped, what you keep and how fast you can move from decision to filing.
- The monitoring alert opens a case file that gathers the transactions, customer profile and prior alerts. The case file goes to the analyst decision. An escalated analyst decision goes to the MLRO determination. The MLRO determination produces the goAML report. The goAML report and the whole case file go to the retained record, which your firm keeps for five or six years because goAML clears processed reports after five days.
Registration comes first
The FIU's page on how to submit a report says that to submit an STR, a reporting entity should be connected to the goAML platform, which is the UAEFIU's reporting platform launched in June 2019. All reports must be submitted electronically via the goAML platform.
Registration has two stages, set out in the FSRA's notice:
- Pre-registration on the Service Access Control Manager (SACM) system of the UAE FIU.
- Registration on the UAE FIU's goAML Portal.
The notice says completion of both stages is mandatory for RPs and their users. The FIU's FAQ adds that the respective Supervisory Body/Regulator will be approving their regulated entities registrations and any changes related to its details or its MLRO/Compliance Officer's details.
None of that is a software feature. It is a dependency: until your MLRO and users are registered, no system can file anything. Our guide to goAML registration and STR filing in the UAE walks through the steps.
Know which report types your workflow must produce
goAML carries more than STRs. The FSRA's Notice 84/2025 lists the report types and triggers firms meet in practice.
| Report | When it applies | Timing stated in Notice 84/2025 |
|---|---|---|
| STR | A transaction, executed or attempted, is suspected to be linked to ML/TF or criminal activity | As soon as practicable and without delay after the MLRO determines suspicion |
| SAR | Suspicious activity, or transactions that appear unusual in source, amount or destination | As soon as practicable and without delay after the MLRO determines suspicion |
| DPMSR | Dealer transactions at or above AED 55,000, in cash or by wire transfer | Within two weeks of the transaction |
| REAR | Real estate transactions involving cash at or above AED 55,000, or virtual assets | Per occurrence |
| PNMR and CNMR | Partial or confirmed name match against the UN or UAE Local Terrorist List | Follow the current EOCN guidance, which postdates the notice |
| HRC and HRCA | Transactions with, or engagement with clients in, high-risk jurisdictions | At least three calendar days before the transaction or engagement |
| AIF, AIFT, RFI | Supplementary information on an earlier report or an FIU request | On request or internal reassessment |
The notice still uses the old name Funds Freeze Report. The EOCN's guidance on targeted financial sanctions, last amended in March 2026, says the Funds Freeze Report (FFR), which was used to report Confirmed Name Matches, has been updated to Confirmed Name Match Report (CNMR). Ask any vendor whose templates or training material say FFR when they will update them.
The high-risk country reports have a consequence for system design. The notice says such reported transaction(s) may only be executed three working days after reporting such to the FIU, and if the FIU does not object. If you process payments to or from listed high-risk countries, your system needs a way to hold a transaction for that window as well as flag it.
Plan for goAML's limits
The FIU's FAQ answers questions that every implementation team runs into. The "Description of the Report" field on the web form holds 4,000 characters. Each attachment size should not exceed 5MB, with a max capacity of 20MB per report. Fraud is not a report type on the goAML, so fraud incidents go in as an STR or SAR with the most suitable reason for reporting. Processed reports remain on goAML web for 5 calendar days before they are cleaned, and draft reports are cleaned up after 15 calendar days.
Key insight: goAML is a reporting channel, and your own system is the archive. It has to hold the case file, the narrative as filed, the attachments and the goAML reference for at least five years onshore and six in the DIFC and ADGM.
If a vendor's answer to "where is the record of what we filed?" is "in goAML", keep looking.
Write narratives an independent reader can follow
The FIU's page on the STR process says an STR includes all relevant information about the suspected crime, including the background, the parties involved, the reasons for the report and possible red flags. The FSRA's notice adds that a quality report must be structured, chronological, and intelligible to an independent reviewer unfamiliar with the case.
Software can help by assembling the timeline and evidence in the order an investigator would explain them. It can't decide that the activity is suspicious. That determination belongs to your MLRO.
The third figure shows the evidence flow from alert to filing. The monitoring alert opens a case file that gathers the transactions, customer profile and prior alerts. The case file goes to the analyst decision. An escalated analyst decision goes to the MLRO determination. The MLRO determination produces the goAML report. The goAML report and the whole case file go to the retained record, which your firm keeps for five or six years because goAML clears processed reports after five days.
What should AML software do for a UAE institution?
The CBUAE guidance describes a monitoring program in seven stages, from risk assessment to post-implementation validation. Each stage translates into a capability you can test. The DFSA and FSRA texts are shorter on mechanics, so the CBUAE stages are a sensible checklist for free zone firms too. If you want the monitoring basics first (scenarios, alerts and investigations), start with our AML transaction monitoring guide.
- The risk assessment sets the requirements. The requirements shape the vendor evidence you ask for. The vendor evidence feeds the pre-implementation test on your historical data. The pre-implementation test goes to independent validation. Go-live waits for independent validation, and after go-live, outcomes monitoring feeds back into the risk assessment.
Start from your risk assessment, not the vendor's scenario library
The CBUAE expects the design of an LFI's TM program to be informed by the LFI's risk assessment, so that TM controls are applied across the full range of risks to which the institution is exposed. LFIs utilizing automated systems should perform a typology assessment to design appropriate rule- or scenario-based automated monitoring capabilities and processes.
Thresholds have to fit your business: LFIs should perform risk-based customer and product segmentation, so that rule parameters and thresholds are appropriately calibrated to the type of activity subject to TM. Ask the vendor to show how its scenarios map to your typology assessment and segments. A library of 200 default rules says nothing about your risks.
Prove the data lineage
LFIs should identify and document all data sources that serve as inputs into their TM program, and source system documentation should include the identification of a system owner. Where automated TM systems are used, LFIs should institute data extraction and loading processes to ensure a complete, accurate, and fully traceable transfer of data from its source to TM systems.
The CBUAE expects data testing and validation at minimum every 12 to 18 months, including the reconciliation of transaction codes across core banking and TM systems. For the CTO, this is the heart of the evaluation. Ask for the reconciliation report format, the exception reports and who owns each feed.
Monitor the customer across accounts
The guidance says that where practicable and on a risk basis, LFIs should monitor transactions at the customer or relationship level, including across financial groups, rather than on an individual account basis alone. The guidance says monitoring a customer across multiple accounts is especially important for customers assessed to be politically exposed persons or as belonging to other high-risk categories. Check that the system resolves one customer across products and, if you run a group, across entities.
Test before go-live, with your own history
Where automated systems are employed, LFIs should perform pre-implementation testing of TM rules and systems, using historical transaction data as appropriate. That testing should include system integration testing and user acceptance testing to ensure that the system performs as anticipated in the operating environment.
For calibration, larger LFIs should consider statistical methods such as above-the-line and below-the-line testing to better fine-tune their calibrations and reduce the volume of false-positive alerts. Our transaction monitoring software acceptance checklist for UAE banks sets out how to run that test once you have a shortlist.
Prioritise alerts and track outcomes
The CBUAE allows risk-weighted alert scoring to prioritize higher-risk alerts for expedited review. It also expects outcome reporting to senior management, which may include an analysis of the number of alerts produced by each TM rule and the proportion of such alerts that are cleared as false positives, that require further investigation, and that end in the filing of an STR/SAR.
Suppression of repeatedly cleared patterns is allowed, but should not be applied to higher-risk customer or transaction types and should be carefully monitored. Ask to see the management information the system produces out of the box, rule by rule.
Keep validation independent
TM model testing and validation should be performed by individuals with sufficient expertise and appropriate level of independence from the model's development and implementation. Post-implementation testing should also include back-testing of TM rules to ensure that they remain current and effective.
If only the vendor can test the system, it fails this expectation. Your internal audit or an independent third party needs access to rules, parameters, test data and results.
Keep a record you can rebuild
Records should be sufficient to permit reconstruction of individual transactions so as to provide, if necessary, evidence for prosecution of criminal activity. Firms must make the records available to the competent authorities immediately upon request. The DFSA adds internal findings and analysis relating to a transaction, whether or not it results in a Suspicious Activity Report.
The record therefore covers more than the transactions. It includes every alert, every decision, the reason and the evidence that the analyst saw at the time.
Connect monitoring to sanctions screening
The CBUAE guidance covers both controls, and expects name screening on an ongoing basis (at least daily) after onboarding. Most UAE institutions buy monitoring and screening together or need them to share a case file. If they come from different vendors, test that a screening hit and a monitoring alert on the same customer land in one investigation. For the screening duties themselves, see our guide to EOCN targeted financial sanctions in the UAE.
The fourth figure shows the selection lifecycle the CBUAE guidance implies. The risk assessment sets the requirements. The requirements shape the vendor evidence you ask for. The vendor evidence feeds the pre-implementation test on your historical data. The pre-implementation test goes to independent validation. Go-live waits for independent validation, and after go-live, outcomes monitoring feeds back into the risk assessment.
What should you ask a vendor before you shortlist?
The CBUAE guidance has a section on vendors, and it reads like a procurement brief. It starts with responsibility: LFIs remain responsible for complying with AML/CFT and sanctions requirements, even if they choose to use third-party models to assist with their compliance obligations. It lists the factors that should guide selection: the LFI's size, geographic footprint, business and technology environments, and financial crimes risks, as well as functional requirements, such as the volume of data to be screened. The list also includes the nature of existing data integrity processes, and the ability of the application to integrate effectively within an LFI's technological infrastructure.
Then it tells you what to demand. LFIs should require the vendor to provide developmental evidence explaining the product components, design, and intended use. Vendors should provide appropriate testing results that show their product works as expected. They should also clearly indicate the model's limitations and assumptions and where the product's use may be problematic. LFIs should expect vendors to conduct ongoing performance monitoring and outcomes analysis, with disclosure to their clients.
It also puts the validation on you. LFIs are expected to validate their own use of vendor products, and where code access is limited the LFI may have to rely more on sensitivity analysis and benchmarking. LFIs should obtain information regarding the data used to develop the model and assess the extent to which that data is representative of the LFI's situation. An LFI's customization choices should be documented and justified as part of validation. LFIs should have contingency plans for instances when the vendor model is no longer available or cannot be supported by the vendor.
Turned into questions, that gives you a shortlist screen:
| Question for the vendor | Why the CBUAE expects it | Evidence to ask for |
|---|---|---|
| What are the product's components, design and intended use? | Developmental evidence | Design documentation, model descriptions, scenario logic |
| What testing shows it works as expected? | Testing results | Test reports on data like yours, with method and base rates |
| Where does it not work, and what does it assume? | Limitations and assumptions | A written limitations statement |
| What data trained or calibrated any model? | Representativeness | Data description by market, segment and period |
| How will you monitor performance after go-live and tell us? | Ongoing outcomes analysis | Sample performance report and disclosure terms |
| How do we validate it without your source code? | Validation of vendor products | Sensitivity analysis access, parameter export, test environment |
| What happens if you stop supporting it? | Contingency planning | Exit plan, data export format, documentation handover |
| Where does our data sit, and who can access it? | Integration with your infrastructure | Hosting options, residency terms, access model |
Two questions sit outside the CBUAE list but follow from the rules above. First, ask how the system records the MLRO's reasons when no report is filed, because DFSA and FSRA firms must keep them. Second, ask how the system keeps the filed narrative, attachments and goAML reference after goAML clears its copy.
Be wary of any accuracy, detection or false-positive figure that isn't measured on your own data with the base rate shown. The CBUAE asks you to validate your own use of the product, and a number from someone else's alerts can't do that for you.
Who decides what when AI agents are part of the system?
AI agents can now do much of the investigation work around an alert: gathering the transactions, comparing them with the customer's history, pulling counterparties and earlier alerts, and drafting the case. That changes the workload. It doesn't change who is accountable. The UAE rules put the reporting determination with the MLRO, and the CBUAE guidance puts responsibility for the system's results on the institution.
- The monitoring system sends each alert to the AI agent layer, which gathers transactions, customer history and counterparties. The AI agent layer sends each case to the analyst with its proposed disposition and reasoning. The AI agent layer also writes every step and data version to the audit trail. The analyst escalates suspicious cases to the MLRO. The MLRO decides on the goAML report, and that decision and its reasons go to the audit trail.
The fifth figure shows that architecture. The monitoring system sends each alert to the AI agent layer, which gathers transactions, customer history and counterparties. The AI agent layer sends each case to the analyst with its proposed disposition and reasoning. The AI agent layer also writes every step and data version to the audit trail. The analyst escalates suspicious cases to the MLRO. The MLRO decides on the goAML report, and that decision and its reasons go to the audit trail. Autonomy settings and a kill switch sit on the agent layer, under the institution's control.
- Federal Decree by Law No. 10 of 2025 and Cabinet Resolution 134 of 2025 set the duties: monitor, keep indicators current, report through goAML without delay, keep records.
- The CBUAE's 2021 transaction monitoring guidance still sets the test for data lineage, scenarios, validation and vendor evidence; the law prevails where they differ.
- DFSA and FSRA firms keep records for at least six years and must record the reasons when no SAR is filed.
- goAML clears processed reports after five days, so your own system has to hold every filing and its case file.
- Software can gather evidence and prepare the case; analysts decide alerts and the MLRO decides and files every report.
Conclusion
Choosing AML software in the UAE is a regulatory decision before it is a technology one. The 2025 law and Cabinet Resolution 134 set the duties: monitor, keep indicators current, report to the FIU through goAML without delay, and keep the records. The CBUAE guidance turns those duties into tests for data, scenarios, alerts, outcomes and validation, and its vendor section tells you which evidence to demand. The DFSA and FSRA add six-year records and recorded reasons for not filing. goAML adds field limits and a short memory, so your system has to keep what you filed.
Write the requirement matrix first. Then ask every vendor the same questions, test on your own data and keep the decisions with your analysts and MLRO.
Request a UAE requirements walkthrough
Frequently Asked Questions
About the author
Sahil Kataria
Founder and CEO of FluxForce
Share this article