The choice of a compliance solution is not based solely on the performance of its engine. It also depends on how the solution integrates with the existing information system, the location of the data, the operational workload, and the ability to scale the architecture over time.
Three terms often come up when evaluating a project to integrate a compliance solution via API: SaaS, API, and on-premise. However, they do not refer to exactly the same thing.
SaaS, which stands for Software as a Service, refers to software that is hosted and operated by the vendor and accessible remotely.On-premise, on the other hand, refers to a solution installed within the organization’s infrastructure. An API, which stands for Application Programming Interface, is an integration method that allows an existing application to automatically call upon the features of a service.
A SaaS solution can therefore be used via a web portal, via an API, or by combining the two.
It is this open architecture that we have adopted at AP Solutions IO. Our solutions are available as SaaS, via a web interface and native APIs, allowing organizations to adapt the integration to their processes rather than having to adapt all their processes to the tool.
What is the difference between a SaaS deployment and an API integration?
SaaS primarily describes how the solution is hosted and operated.The API describes how another system communicates with it.
The two are therefore complementary.
SaaS with a Web Portal
With a SaaS portal, users access an interface provided by the vendor, typically through a web browser.
The company does not have to deploy the solution on its own servers or directly manage its application infrastructure. This can significantly reduce the technical burden compared to an on-premises installation.
However, there are still several steps to take:
- creation of access points;
- configuration;
- definition of user profiles;
- rule configuration;
- any data imports;
- Organization of alert-handling processes.
The portal is therefore a useful option when compliance teams need a dedicated environment to perform or oversee their controls.
At AP Solutions IO, we offer a web interface that allows teams to use the features of our solutions directly, without requiring prior integration into the information system.
API Integration
An API allows a business application to query the compliance solution directly.
For example, a check can be triggered when a customer is created in a CRM system, during a KYC process, or from a banking app. The result is then sent back to the system that initiated the request.
This allows the user to remain in their usual environment if the user flow has been designed that way. The API alone does not guarantee a completely seamless experience; that depends on the client-side implementation.
Our technology works precisely according to this principle. AP Solutions IO’s native APIs can be called from an IT system, a CRM, a KYC/KYS tool, an HRIS, or other applications. Our page dedicated to the features to consider in a compliance solution allows you to consider this integration issue alongside other selection criteria.
On-premises mode
The on-premises model involves deploying the solution within the organization's IT environment.
This architecture can address certain internal policies or specific infrastructure constraints. However, it requires handling more tasks in-house: deployment, monitoring, security, maintenance, version upgrades, and infrastructure management.
The issue, therefore, is not simply a matter of weighing “control” against “simplicity.” It is necessary to determine what level of technical responsibility the organization wishes to retain and what resources it can mobilize over the long term.
Which mode should you choose based on your needs?
It is more useful to compare architectures based on their operational implications than to seek a universal model.
| Criterion | SaaS with a portal | SaaS + API | Hybrid: Portal + API | On-premises |
| Application Infrastructure | Managed by the publisher | Managed by the publisher | Managed by the publisher | Managed in-house |
| Integration with the Information System | Limited or optional | Required | Depending on the process | Depends on the project |
| User Experience | Dedicated interface | Can remain in the business tool | Tailored to individual profiles | Depends on the application |
| Application Updates | Managed by the publisher | Managed by the publisher | Managed by the publisher | To be organized internally |
| Operating Expenses | Generally limited | Limited on the hosting side; client-side IT project | Varies depending on the integration | Most important |
| Appropriate Use | Independent Compliance Team | Automated processes and high volumes | Mixed needs | Specific infrastructure constraints |
The effort required for integration depends on the chosen path
A SaaS portal can eliminate the need to develop a full-fledged application interface, but that doesn't mean there's no deployment work involved.
Conversely, an API requires technical integration:
- definition of the transmitted data;
- authentication;
- response management;
- error-handling rules;
- Alert Workflow.
AP Solutions IO uses OAuth2-secured REST/JSON APIs designed to facilitate integration with existing systems. At the same time, our no-code configuration allows you to configure business rules without turning every adjustment into a development project.
The charge moves; it doesn't disappear
With an API, some of the effort is shifted from day-to-day use to the integration project.
This is often useful when there is a large volume of checks or when the organization wants to automatically trigger a screening step in a business process.
With a portal, the integration effort is reduced, but users must work within a dedicated interface.
The choice therefore depends more on processes, volumes, and team organization than on a theoretical hierarchy between the two models.
Do you have to choose between a portal and an API?
Not necessarily. A hybrid mode allows you to combine the two.
The API can automate the checks built into business workflows, while the portal provides compliance teams with a dedicated space for qualifying, processing, and tracking alerts.
Different interfaces for different needs
An operational user who creates a customer in a business application does not necessarily need access to the entire compliance engine interface.
Conversely, an analyst must be able to review an alert, consult the relevant information, make a decision, and document it.
With AP Solutions IO, we enable the same functions to be used via the web interface or called directly by a third-party system through our web services. This setup allows you to choose the access point based on the user’s profile.
The architecture and technology of AP Solutions IO are based precisely on this philosophy of openness.
A phased rollout remains possible
An organization can also start by using a portal and then gradually automate certain workflows via APIs.
In particular, this approach makes it possible to test the rules, monitor alert volumes, and fine-tune the settings before proceeding with more extensive integration.
However, it is not mandatory. When an information system and processes are already clearly defined, API integration can be planned from the outset.
The key is to choose a sequence that is consistent with the project's constraints, rather than systematically applying the same deployment plan.
How can a screening solution be integrated into an existing core banking system?
An open architecture allows a screening engine to be called from a core banking system, a CRM, or another business application.
The project begins by identifying the times when the inspection must be performed.
Identify the right integration points
According to the provisions, an appeal may be filed when:
- establishing a relationship;
- updating a file;
- a review of the existing portfolio;
- an event requiring further verification;
- the processing of a data stream when a filtering tool is involved.
The choice must be based on the compliance framework and risk assessment, not solely on the API’s technical capabilities.
Check the data that is actually available
Effective integration also depends on the quality of the data transmitted.
A search engine that is given only a name has fewer criteria for distinguishing between homonyms than a search engine that is also given a date of birth, a country, or other relevant information.
Any discussion of the API must therefore include data mapping: What information is present in the source system? In what format? At what point is it reliable enough to initiate the check?
Define what happens when an alert appears
The integration must also include provisions for managing the results.
Depending on the context, a correspondence may result in a hold, a request for review, a notification, or another course of action determined by the organization’s procedures.
The API triggers the process and returns control; it does not, on its own, determine which business procedure to apply.
This distinction aligns withAP Solutions IO’s approach: our tools automate detection and provide traceable results, but the processing and governance must remain consistent with the organization’s rules.
Work with integration partners when necessary
An integration can be carried out by in-house teams or with a technology partner.
AP Solutions IO works with Elcimaï, among others, which integrates AP Scan and AP Filter into its core banking environments. Other integrations also allow our APIs to be embedded directly into business platforms.
Our page dedicated to AP Solutions IO’s partner ecosystem features several examples of these connections.
Is the on-premises model still relevant?
Yes, in certain architectures.
An organization may wish to continue operating certain components within its infrastructure due to internal policies, technical constraints, or legacy architecture.
But this level of control comes with additional operational responsibilities: technical resources, security, backups, updates, and ensuring availability.
Compare actual control, not just the hosting provider
An in-house infrastructure does not automatically guarantee better control. Control also depends on procedures, available expertise, supervision, and the ability to regularly apply the necessary updates.
Conversely, a SaaS solution outsources part of the operations but requires a careful assessment of hosting, security, availability, subcontracting, contractual terms, and the ability to switch back to an on-premises solution.
For AP Solutions IO, we have opted for a web-based, SaaS, and full-API architecture, with data hosted in France. We therefore do not base our offering on an on-premises model, but rather on a hosted architecture designed to integrate seamlessly with existing IT systems.
What questions should you ask before choosing an architectural style?
Before deciding on a method of use, several questions must be addressed together:
- What volume should be monitored, and how often?
- Which business events should trigger the checks?
- In which applications is the data available?
- Where do compliance teams want to handle alerts?
- What level ofautomation is desired?
- What security and hosting requirements must be met?
- What IT resources can be allocated to integration?
- What level of reversibility is expected at the end of the contract?
A large volume of data does not automatically require an API, but it can make automation particularly useful. Similarly, a portal can be suitable for an independent compliance team without precluding future integration.
How AP Solutions IO Approaches the Deployment of an API-Based Compliance Solution
AP Solutions IO is a French RegTech company specializing in compliance technologies AML-CFT, KYC, anti-corruption, and export control.
Our suite includes AP Scan for screening, AP Scoring for risk assessment, AP Monitoring for transaction monitoring, and AP Filter for sanctions and embargo screening.
Our solutions featureweb interfaces, SaaS, and native APIs, with an open architecture and no-code configuration. The data is hosted in France.
This choice allows for compliance to be integrated in various ways:
- direct use by teams;
- calls from a CRM or management system;
- integration into a core banking system;
- a combination of several modes, depending on the process.
The goal, therefore, is not to choose between SaaS and APIs in the abstract, but to determine how the various access and integration methods should work together. With AP Solutions IO, we aim to determine how the technology should be integrated into the information system to automate controls without disrupting business workflows or limiting teams’ ability to understand and track results.
To identify the relevant call points, the available data, and the level of integration best suited to your architecture, you can discuss your integration project with our team.
