Developing a Data Strategy

1. I would prioritize training of staff in data analytics, statistical modelling, and digital risk assessment. The Bank must invest in building the human capital to interpret and act on data because without analytical capacity inside the institution, sophisticated tools will remain underutilized.

2. The main challenges would be skills gap amongst the staff to analyze and make meaning out of collected data in addition to low Data Quality from Reporting Institutions which would undermine the entire strategy.

The first reform I would propose is to define a minimum supervisory dataset that every licensed entity must report, using one ECMA data dictionary with clear definitions, required fields, and reporting frequency. This is essential because, in a new market, data inconsistencies quickly become supervisory blind spots. In parallel, I would standardize unique identifiers across the ecosystem, firm ID, client account ID, instrument ID, order ID, trade ID, and settlement ID. Without common identifiers, it is difficult to trace a client journey from onboarding, to order placement, to execution, to settlement, and then to complaints or losses.
The second reform is to move reporting away from narrative submissions and PDF documents toward structured, machine readable templates. At the beginning, this can be disciplined Excel templates with locked fields and validation rules, then progressively migrate to more automated submissions as capacity improves. This shift matters because risk based supervision depends on comparability across firms and time, and documents are not comparable at scale. Alongside structured reporting, I would introduce a data quality regime that includes automated checks for completeness, internal consistency, reconciliations between trading and settlement records, and exception reporting. I would also require senior management attestation for periodic returns so accountability sits where it belongs.
The third reform is to build a single supervisory data repository inside ECMA that integrates licensing data, periodic returns, onsite findings, incidents, complaints, and enforcement outcomes. Even if the technology is simple at first, the governance must be strong, role based access, audit logs, and a clear process for who can change data definitions and templates. In a young market, the biggest risk is fragmentation, each directorate building separate spreadsheets and separate definitions. A single repository supports consistent risk scoring, supervisory planning, and quicker escalation when problems repeat.
The fourth reform is to formalize data sharing with market infrastructure providers, especially the Exchange and the CSD, through a clear operational protocol. My aim would be near real time or frequent feeds for key supervisory indicators such as order and trade data, settlement fails, cash and securities reconciliation exceptions, corporate actions exceptions, and system outages. This allows ECMA to monitor market integrity and operational resilience without waiting for monthly narratives. Finally, I would sequence SupTech realistically. I would start with dashboards, automated validations, and exception alerts on a small set of high impact indicators, then expand to network mapping and early warning indicators. Only once the data is stable and clean would I introduce AI enabled analytics, because weak data produces confident but wrong outputs.
The main challenges to implementing this data strategy are predictable in the current reality. The first is data quality at source. Many firms will still be stabilizing systems and processes, and some records will be manual or inconsistent. The second is coordination across institutions, because effective risk mapping requires consistent data flows between intermediaries, the Exchange, and the CSD, and the incentives and operational priorities do not always align. The third is capacity, both technical capacity to build and maintain a data platform, and supervisory capacity to interpret analytics and translate it into supervisory action. The fourth is cost and procurement constraints, which can force the organization to rely on workarounds longer than intended. The fifth is change management, because firms may view new reporting as a burden unless ECMA explains the purpose, phases the rollout, and provides clear guidance and feedback loops. The sixth is confidentiality and cyber risk, since richer datasets increase the consequences of poor access control, weak governance, and inadequate incident response. The seventh is that a new market has limited history, so risk thresholds and peer benchmarks will initially be uncertain and must be conservative and frequently recalibrated.
Actionable way to start immediately:
1. Approve a minimum supervisory dataset and one data dictionary, then pilot it with a small number of core returns.
2. Establish a joint ECMA, Exchange, CSD technical working group to align identifiers, formats, and frequency for key feeds.
3. Deploy basic validation rules and exception reporting, then publish clear supervisory feedback so firms improve submissions quickly.
4. Build a simple central repository and dashboard focused on the highest risk indicators, client funds, settlement fails, outages, complaints, and repeated breaches.

1. If I were to design a data strategy at SBP, I would prioritise improving data quality and consistency first, including standardised reporting templates and clearer data definitions. I would also gradually move toward more granular data collection in high-risk areas like e-money, fraud, and agent networks, while upgrading data infrastructure to support scalability and interoperability across departments.

2. The main challenges would likely include legacy systems, limited data analytics capacity, resistance to change, and ensuring strong data governance, especially if moving toward more advanced SupTech or AI-based tools.