SAS
Analytics-led AML suite
SAS Anti-Money Laundering brings monitoring, customer due diligence, entity resolution, investigation, and reporting into an integrated application. The current generation runs on SAS Viya. Its main distinction is the connection between operational AML work and configurable analytics, rather than identity capture at the front of an onboarding flow.
Our assessment
A deep AML and analytics candidate; broad corporate software coverage should not be treated as one ready-made risk stack.
Best fit and limitations
Fits organizations that want AML operations and a strong analytics environment under one architecture. It is especially worth testing when the team can own model design, data quality, and tuning.
- Separate the current Viya product from older SAS AML installations. Migration can change workflows and infrastructure.
- A visual scenario editor does not remove the need for data engineering or model validation.
- Confirm external screening content and IDV/KYB providers; AML CDD does not itself prove legal identity.
Tools 5
SAS Anti-Money LaunderingDetection and compliance+
- Configured scenarios with ML and network analysis
- Customer-level triage and investigation
Customer Due DiligenceCustomer-level AML risk review+
- Use demographic and behavior triggers for CDD and EDD
- Guide review with dynamic checklists
- Combine related entities and investigation context
Entity resolution + network analyticsConnected investigations+
- Deduplicate entity records and reveal links
- Examine ownership and counterparties
Open administrationOperating controls+
- Visual scenario authoring and workflow configuration
- Tailored screens, exploration, and reporting
Real-Time Watchlist ScreeningScreening extension+
- Separate named screening product in the SAS portfolio
- Confirm purchased engine, datasets, and payment-message scope
AI capabilities
Predictive analytics + model governance
The reviewed product material establishes anomaly detection, ML, explainability, and network analysis. It does not establish a specific autonomous AML agent included in every deployment.
What to validate
Ask for feature lineage, model validation, threshold change approval, and performance by customer segment.
Implementation
Integration checklist
- Ask for a Viya architecture and data ingestion design for the target environment.
- Assess source quality, entity matching, historical transaction loads, and access controls.
- Confirm exactly which reporting templates and submission interfaces apply to your jurisdictions.
Commercial scope
Quote required. Separate application licensing, infrastructure, implementation, data preparation, model work, and support.
Questions for the demo
- Which AML version and Viya services are included?
- Can our team build, backtest, approve, and roll back a new scenario?
- What remains manual between case closure and report submission?
Engineering
- Inputs
- External application data store using Oracle Enterprise 19c or later, or PostgreSQL
- Outputs
- Customer-level investigation cases and retained audit actions · Customer-level triage and retained case actions for audit
- Webhooks
- Not verified in public documentation.
- Decision timing
- No measured latency or contracted response time verified.
- Deployment
- Cloud-native (Viya 4) · Viya on supported AWS, Azure, Google Cloud, or OpenShift deployments; distribution support varies
- Dependencies
- SAS Viya 4 for the current AML application · SAS support or a consultant must supply an access key for current AML manuals · SAS Infrastructure Data Server/PostgreSQL plus the external data store · Additional persistent PostgreSQL storage for internal AML entities · UTC+00 on AML platform and solution machines, and the Oracle database when used
Verified details 10
- Outputs
Customer-level investigation cases and retained audit actions
Source Checked 2026-09-18 - Outputs
Customer-level triage and retained case actions for audit
Source Checked 2026-09-18 - Deployment
Cloud-native (Viya 4)
Source Checked 2026-09-18 - Dependency
SAS Viya 4 for the current AML application
Source Checked 2026-09-18 - Dependency
SAS support or a consultant must supply an access key for current AML manuals
Source Checked 2026-09-18 - Inputs
External application data store using Oracle Enterprise 19c or later, or PostgreSQL
Source Checked 2026-09-18 - Deployment
Viya on supported AWS, Azure, Google Cloud, or OpenShift deployments; distribution support varies
Source Checked 2026-09-18 - Dependency
SAS Infrastructure Data Server/PostgreSQL plus the external data store
Source Checked 2026-09-18 - Dependency
Additional persistent PostgreSQL storage for internal AML entities
Source Checked 2026-09-18 - Dependency
UTC+00 on AML platform and solution machines, and the Oracle database when used
Source Checked 2026-09-18
Illustrative contract
An example for your internal adapter. This is not a vendor endpoint, request, or response.
{
"contract": "internal-risk-review/v1",
"vendorId": "sas",
"internalCorrelationId": "example-001",
"vendorRecordId": null,
"control": "Detection and compliance",
"evidence": [],
"status": "pending",
"decision": "review",
"requiresHumanReview": true
}Integration limits
- Illustrative internal integration contract. This is not a vendor request, response, endpoint, or SDK example.
- Empty country, deployment, or provider lists mean not verified in this review. A documented country refers to the specific product noted in its source, not universal platform coverage.
- This support page distinguishes the Viya release from older AML versions. It does not establish every cloud provider, deployment region, or a public ingestion schema.
- Generic SAS developer APIs were not treated as evidence of a specific AML endpoint.
- These are AML requirements in the v_068 platform guide, not a guarantee that all cloud database distributions or current releases are interchangeable.
Sources 3
Source review dates are shown above. Product claims come from public sources. Fit, limits, and evaluation questions are our analysis. This is not a hands-on performance test. Methodology · Changelog