Mopso is a European regtech company providing AML solutions to financial intermediaries. Its software platform consists of tools and services to manage AML Customer Due Diligence (CDD) and to discover money laundering schemes by integrating and analyzing information from multiple data sources. Mopso platform operates in the Self-Sovereign Identity framework, and it is compliant, by design, with all AML, privacy, and security best practices and regulations.
The Mopso platform discovers and organizes the AML information according to the latest W3C standards. Behind the scenes, Mopso describes any financial operations into a set of formal statements that are stored in a knowledge graph together with their related meta-data. Mopso uses cryptography, blockchain, AI algorithms and provides an intuitive UX to speed up the AML process. Thanks to the use of ontologies, verifiable credentials, and logic computation, Mopso provides software agents that navigate the knowledge graph, find suspicious patterns, display relevant data, compute risks, etc. Those software agents can be theorem solvers, network analyzers, or neural networks.
The Mopso architecture defines the following architectural elements, better explained in the next chapters:
Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words may not always appear in uppercase letters in this specification.
The Mopso jargon is composed by the following terms that are defined/used inside this document:
|terms used in offering integration:||data component, knowledge graph, legacy system, MVP, offering, ontology, package, rdf, reasoner, SDaaS, service component, SLA, software agent, sparql, system component, SSI, UX, web app|
|terms used in software integration:||address space, api, ASA, authentication, authorization, database object, data trasformer, deploy configuration, documentation library, front end, interface type, KEES, language profile, log, message object, object store, proxy, RESTful, SDaaS gateway, SDK, SDaaS internal processor, SDaaS rule processor, singleton, stdin, stdout|
All Mopso platform features are available in a set of commercial offering components:
Offerings must be described in an offering document and customized on user requirements.
The Mopso reference offering is composed of these items:
|Amlet||a Cloud SaaS that extends the Self-Sovereign Identity framework (SSI) to support AML W3C Verifiable Credentials for Customer Due Diligence (CDD) by complying with both the Progressive Trust principle and AML regulations|
|Brain||realizes the AML knowledge graph, linking all the information from various data sources, managing the data ingestion and computing inferences, available both on customer premises or as a Cloud SaaS|
|Net||is a cloud service that provides open source intelligence (OSINT) through a set of federate knowledge base realized with Mopso Brain|
|Mopso language profile||is a formal language that makes possible to model suspicious operations as propositions expressed in the first order logic, thus making it possible to treat suspicious operations as automatically demonstrable theorems. It adopts well known ontologies and vocabularies extended with AML specific concepts|
|AML2||AML tools and professional services assisted by machine learning and Mopso tools|
|Integration services||templates, documentation and professional services to support integration activities|
|Touch||is a Machine Learning framework to analyze data streams, identifying suspicious patterns not discovered by other tools|
|Vision||realizes interactive features (i.e. UX) used by the bank’s staff responsible for managing unexpected AML events. It helps AML manager to identify false positives in the detected suspect operations. It allows to navigate and validate the predictions made by the brain and touch packages|
For more info about the Mopso offering visit http://mopso.eu/
Commercial offerings may include a set of modular packages licensed by Mopso that contain a subset of systems, service features, and data components.
Packages may depend on each other and may have incompatibilities both from a technical and/or commercial point of view. The packages configuration that build-up an offering MUST be described in the offering document.
Custom packages may be developed and licensed to cover special user needs to be defined in an offering.
Each solution MUST provide a documentation package describing how to install, integrate and deploy the solution. It MUST provide a Bill Of Material of all the included components together with their license and version info.
The following requirements apply to the technical documentation:
- all mandatory dependencies MUST be fulfilled.
- incompatible components MUST NOT present.
- each provided component MUST have a release number compliant with the [Semantic Versioning standard]
The technical documentation SHOULD be used to drive integration activities and maintenance plans.
Service Level Agreement
Commercial offerings that include servicesMUST define SLA (Service Level Agreement). Custom services may be developed to cover special user needs to be defined in an offering.
There are six main systems components types:
- Knowledge graph dataBase (KB) providing RDF storage persistence with a SPARQL endpoint
- Web app (WAPP) providing web frontend
- APIs (API) providing REST web services interface
- Legacy Proxy (LP) provides a Linked Data gateway to legacy data. It can execute in-band ETL processing.
- Autonomous Agents (AA) is a software process that independently discovers new data. They can provide out-of-band-band ETL processing.
- Autonomous Sidecar Agents (ASA) providing KB sidecar containers implementing data processing features, further divided into:
- Ingestion Agents (IA) that provides ETL processing and data bridge between federated knowledge bases;
- Real-Time Reasoners (RTR) that materialize inferences on a knowledge base
The system components MUST implement all mandatory interface and a least one of the optional interfaces in this list:
|ENV||mandatory||Config Interface||Service configuration options passed through environment variables and/or startup options|
|LOG||mandatory||Log Interface||a logging feature compatible with the Docker Log commands|
|OC||mandatory||Operator Console||a basic compatible bash shell through ssh protocol providing STDIN and STDOUT|
|EI||optional||External Interface||custom interface used to access data from legacy system or external data providers through unspecified protocols and formats|
|FS||optional||File System Interface||a POSIX compliant sharable file system interface (can be readonly)|
|LDR||optional||Linked Data Resource||a RESTFULL interface providing Linked Data|
|MOC||optional||Mopso Operator Console||an Operator Console supporting Mopso SDaaS commands|
|API||optional||RESTfull APIs||generic http based application program interface compliant with the RESTful architecture|
|SQ||optional||SPARQL QUERY||an endpoint compliant with the SPARQL 1.1 protocol specification providing the sd:SPARQL11Query and the sd:UnionDefaultGraph features|
|SU||optional||SPARQL UPDATE||an endpoint compliant with the SPARQL 1.1 protocol specification providing the sd:SPARQL11Update, the sd:UnionDefaultGraph features, and the SPARQL 1.1 Graph Store HTTP Protocol support|
|SWB||optional||SDaaS Workbench||a web application providing browsable user access to a knowledge graph|
|WAPP||optional||Web App Interface||a web application providing browsable user access|
|WR||optional||Web Resource||an unspecified web resource according the definition in W3C web Architecture|
|LI||optional||Local Interface||A generic user interface on local client|
(This table was extracted from Mopso components catalog)
These requirements apply to all system components:
- each system component MUST be realized as a Docker container running under the control of an orchestrator ( e.g. Kubernetes or docker-compose).
- each system component MUST have a dedicated GIT repository and documentation;
- each system component MUST have a name that is unique in all Mopso documentation;
- each system component MUST have a release number compliant with the [Semantic Versioning standard]
- each system component SHOULD provide its helm chart
- each system component SHOULD be stateless
- KB components COULD be stateful
- system components dependencies and incompatibilities MUST be documented in the component repository
- each system component SHOULD define a Time To Live (TTL) period in seconds. On TTL expiration, the component SHOULD die and OPTIONALLY it should be restarted to mitigate memory leaks risks
Knowledge Graphs (KB) requirements
Knowledge Graphs provide the linked data persistence. They are graph databases that organize data according to the RDF standard by W3C. All knowledge graphs are services that MUST provide a SPARQL endpoint for query and update operations (SQ & SU), MUST provide an RDF file exchange area to sidecar components) and SHOULD provide a graph store interface (GS).
The knowledge graphs:
- MAY be derived from SDaaS platform product.
- MUST follow the KEES principles. In particular, all information contained in the knowledge graph MUST be expressed with a defined [language profile]
- MUST assume the open world hypothesis.
- If no new facts appear, the KEES cycle (Boot, Learn, publish)* SHOULD* converge quickly to a stable configuration. A stable configuration is defined as a knowledge graph whose SPARQL query service always answers the same semantic result to the same query.
- MUST expose LOG, ENV, SQ, SU interfaces.
- COULD be attached to an Object Store that provides a temporary, read-only share where to access Linked Data provided by other components.
- COULD be able to rebuild itself at the start, converging in a stable status in a finite time frame. (depending on the complexity and the quantity of data) in this case, it MUST be considered a stateless service
- MUST provide a way to introspect its status
- SHOULD provide data access also during the rebuild. In this case, the result COULD NOT be accurate.
Legacy Proxies (LP)
Proxies are a synchronous gateway that MUST expose an LDR interface. They MAY implement OC, ENV, and LOG interfaces.
An LP component COULD provide synchronous ETL processing (i.e., filters) to external raw data. Results SHOULD support HTTP cache protocol.
Autonomous Agent (AA)
It is a component that produces a-synchronically a data file suitable to be ingested by an external application (e.g., an LP).
AA components are used to enrich first-party data by discovering and processing second and third-party data.
A AA component MAY provide ETL processing and local temporary storage.
Web Services (API)
API is an HTTP server that queries the knowledge graph and exposes the results in an application-specific format. APIs MUST implement ENV and LOG interfaces. Dependencies to nonstandard SPARQL service features MUST be documented.
APIs MAY be Mopso SDaaS instances.
Web Frontend (APP)
The frontend is an API that provides web resources that can be rendered by any HTML5 and ECMAScript compatible browser.
They SHOULD adopt a microservice architecture, and they MUST implement ENV and LOG interfaces.
Access to public internet resources MUST be ensured to all main web browsers.
Autonomous Sidecar Agents (ASA) requirements
ASA components are sidecar instances that connect runtime to a KB component to extend its capability.
The following requirements apply to all ASA kinds:
- they MAY share data using ephemeral volumes with kb
- ASAs MAY include a private and ephemeral KB instance for local processing.
- all ASA interfaces MUST be described in terms of protocol, accepted formats, and data models;
- input and output examples MUST be provided as documentation or (better) as an automated test;
- runtime docker memory footprints SHOULD be less than 512K (excluding temp storage);
- ASA SHOULD be resilient to knowledge graph failures;
- they MUST be stateless
Real-Time Reasoners (RTR)
RTRs are ASA plugins extending the reasoning capability of a KB system.
Following requirements apply:
- MAY be derived from SDaaS platform product.
- MUST NOT connect to any external system except the kb.
- MUST materialize inferences in the connected knowledge graph.
- once booted, they SHOULD continuously run a reasoning cycle
Ingestion Agents (IA)
IAs are ASA plugins like RTR with the main objective of providing ETL process to a KB system. The following requirements apply:
- once booted, they SHOULD continuously run a KEES cycle (i.e., learning, reasoning, teaching windows)
Data components are responsible for data persistence. Each data component is realized as a kubernetes volume that is attachable by multiple system components
Some data components can be prefilled with upgradable data or just remote read-only datastore.
The following requirements apply to all data components:
- data components MUST be realized as Docker volumes.
- data components MAY be declared as “read-only”.
- data components MUST be identified by an unique id ( name space ) in the Mopso platform installation.
- data components MUST provide a FS Interface.
- data components MAY be a single file or a directory.
- in the system components the Object Stores mount point SHOULD be /data/