Financial Services · Moraph software

AML & SAR Automation Hub

Find suspicious activity, investigate it, and prepare the SAR, in one place

Book a demonstrationRequest a technical briefingFactsheet

Overview

What you are buying

The AML & SAR Automation Hub monitors transactions for structuring, layering and other suspicious patterns, and turns alerts into cases your investigators can work. It drafts the FinCEN Suspicious Activity Report from the case, so your BSA officer reviews, approves and files it. Every alert, decision and report keeps its reasoning and evidence, ready for internal audit and examiners.

The problem it solves

Most BSA/AML teams work across a monitoring system that produces alerts without context, spreadsheets that track cases, and a separate process for writing and filing SARs. Analysts spend their time gathering transactions and customer files rather than judging them, false positives crowd out the cases that matter, and filing deadlines are tracked by hand. When examiners ask why an alert was closed or how a threshold was set, the answer is spread across emails, notes and memory.

  • Alerts arrive without the reasons or related activity an analyst needs to decide
  • Case files are assembled by hand from several systems
  • SAR narratives are written from scratch and deadlines tracked in spreadsheets
  • Tuning decisions and closed alerts are hard to evidence at exam time

Who uses it

  • BSA/AML officers and investigators at banks and credit unions
  • AML analysts who triage alerts day to day
  • Compliance leadership who answer for the program
  • Model risk and analytics teams who tune detection scenarios
  • Internal audit and examiners, who need evidence of every decision

Requirements it supports

Bank Secrecy Act (31 U.S.C. 5311 et seq.)FinCEN SAR rules (31 CFR 1020.320 for banks)FinCEN Customer Due Diligence Rule (31 CFR 1010.230)FFIEC BSA/AML Examination ManualUSA PATRIOT Act Section 314 information sharingInteragency Guidance on Model Risk Management (SR 11-7)

The product supports these requirements; meeting them remains your organization’s responsibility.

See how it works

A short walkthrough

Illustrative screens with fictional sample data. They show the workflow, not any client’s data or configuration, and the layout of the product itself differs. A live demonstration uses the product with sample data.

  1. Step 1

    The alert queue

    Analysts start from one queue of open alerts, grouped by customer, with the scenario, risk and age of each.

    AlertCustomerScenarioRiskAgeStatus
    AL-20417Customer 10482Cash deposits just below reporting thresholdHigh2 daysNew
    AL-20409Customer 77310Rapid in-and-out wire activityHigh3 daysIn review
    AL-20388Customer 31954Activity unusual for customer profileMedium4 daysIn review
    AL-20371Customer 58821Round-dollar transfers between related accountsMedium6 daysEscalated
    AL-20366Customer 10944Dormant account reactivatedLow6 daysNew
    Analysts start from one queue of open alerts, grouped by customer, with the scenario, risk and age of each.

  2. Step 2

    Why the alert fired

    Each alert explains itself: the scenario, the factors that contributed and the transactions involved.

    Customer 10482 · Structuring scenario

    Scenario
    Cash deposits just below reporting threshold
    Period
    14 days
    Deposits in pattern
    9 at 4 branches
    Total
    $84,600
    Customer risk rating
    Medium (from onboarding)

    Contributing factors

    • Deposits between $8,000 and $9,900 on 9 of 14 days
    • Four branches used within one week
    • No similar pattern in the previous 12 months
    Each alert explains itself: the scenario, the factors that contributed and the transactions involved.

  3. Step 3

    The customer view

    Everything known about the customer sits beside the alert: risk rating, due diligence, owners and history.

    Customer 10482 · Example Landscaping LLC (fictional)

    Customer type
    Small business
    Risk rating
    Medium
    Expected activity
    Card receipts, some cash
    Beneficial owners
    2 on file
    Prior alerts
    1, closed
    Prior SARs
    None

    Due-diligence notes

    • Business purpose verified at onboarding
    • Expected monthly cash recorded at onboarding
    • No 314(a) matches on last search
    Everything known about the customer sits beside the alert: risk rating, due diligence, owners and history.

  4. Step 4

    The investigation

    The case keeps the evidence, the analyst's notes and the decision, with a second approver before anything is filed.

    Case CS-3318 · Customer 10482

    1. Alert AL-20417 escalatedAnalyst
    2. Related accounts and earlier alerts linkedAnalyst
    3. Customer due-diligence file reviewedAnalyst
    4. Recommendation: file SAR, with rationaleAnalyst
    5. Recommendation approvedBSA officer
    The case keeps the evidence, the analyst's notes and the decision, with a second approver before anything is filed.

  5. Step 5

    The SAR draft

    The draft report is pre-filled from the case, with the narrative to complete and the filing deadline in view.

    SAR draft · Case CS-3318

    Subject
    Customer 10482
    Activity type
    Structuring
    Amount involved
    $84,600
    Activity dates
    Fictional sample period
    Filing due
    Shown from the date of detection

    Narrative sections

    • Who is conducting the activity
    • What instruments were involved
    • When and where it occurred
    • Why it is suspicious
    • How it was carried out
    The draft report is pre-filled from the case, with the narrative to complete and the filing deadline in view.

  6. Step 6

    Testing a threshold change

    Before a threshold changes, the Hub shows what the change would have done to past alerts, and keeps the result as evidence.

    ScenarioCurrent thresholdProposedAlerts (current)Alerts (proposed)SAR cases missed
    Cash just below threshold$8,000 to $9,999$7,500 to $9,9991421880
    Rapid in-and-out wires3 in 5 days4 in 5 days96611 to review
    Dormant account reactivated180 daysNo change38380
    Before a threshold changes, the Hub shows what the change would have done to past alerts, and keeps the result as evidence.

Workflows

The principal workflows

  1. Monitor

    Transactions from your core and payment systems are scored against detection scenarios and models for structuring, layering, rapid movement of funds and activity that is unusual for the customer's profile.

    • Transaction, account and customer data arrive by scheduled file or API
    • Data quality checks flag missing or malformed records before scoring
    • Each scenario and model scores the activity against its thresholds
    • Alerts are created with the factors that produced them
    • Related alerts for the same customer are grouped together

  2. Triage

    Alerts are grouped by customer in a single queue, each showing why it fired and the related activity, so analysts close obvious false positives quickly and escalate the rest.

    • Queue sorted by risk, age and customer
    • Analyst opens the alert and reviews the contributing factors
    • Customer profile, risk rating and prior alerts shown alongside
    • Alert closed with a reason code and note, or escalated to a case
    • Closed alerts sampled for quality review

  3. Investigate

    A case brings together the transaction timeline, counterparties, earlier alerts and cases, customer due-diligence data, notes and attachments. The decision to close or escalate is recorded with its rationale.

    • Case opened from one or more alerts
    • Transactions, counterparties and linked accounts gathered automatically
    • Investigator adds research, notes and documents
    • Recommendation to file or not file written with rationale
    • A second reviewer approves or returns the recommendation

  4. Report

    For escalated cases the Hub drafts the SAR from the case data, with a narrative structure for the investigator to complete. A second person approves it, and the Hub tracks the filing deadline and continuing-activity reviews.

    • SAR draft pre-filled with subject, activity type, amounts and dates
    • Investigator completes the narrative using the five-part structure
    • BSA officer reviews and approves the draft
    • Approved report exported for BSA E-Filing and the acknowledgment recorded
    • Continuing-activity review scheduled on the filed case

Roles and permissions

Who does what in the product

Each role below is a starting point. During implementation we set them up to match your teams, and every action anyone takes is recorded in the audit trail.

AML analyst

AML analyst, BSA analyst, transaction monitoring analyst

Works the alert queue and decides, with a recorded reason, whether each alert is closed or escalated to a case.

Sees

  • Alerts assigned to them or their team's queue, with the factors that produced each one
  • The customer risk view: risk rating, due-diligence data and earlier alerts and cases
  • Transactions and related accounts behind each alert
  • Their own open work, sorted by risk and age

Does

  • Opens alerts and reviews the contributing factors and related activity
  • Closes alerts with a reason code and a note
  • Escalates alerts to a case for investigation
  • Groups related alerts for the same customer
  • Adds notes and attaches supporting research
  • Runs 314(a) searches when assigned

Cannot

  • Draft, approve or export a SAR
  • Change scenarios, thresholds or reason codes
  • Reopen or edit an alert after quality review has recorded a finding on it
Approvals
Their closures can be sampled by a quality reviewer, and their escalations are taken up by an investigator; nothing they do needs their own approval.
Notified about
New alerts assigned to them, alerts approaching the age your procedures set, and alerts returned to them after quality review.

Investigator

AML investigator, financial crimes investigator, senior BSA analyst

Investigates escalated activity and recommends whether a SAR should be filed, with the rationale written down.

Sees

  • Cases assigned to them and the alerts that opened each case
  • Transaction timelines, counterparties, linked accounts and beneficial owners
  • Earlier cases and SARs for the same customer, where their role allows
  • SAR drafts for their own cases

Does

  • Opens cases from one or more alerts and links related accounts
  • Gathers evidence, adds research notes and attaches documents
  • Writes a recommendation to file or not file, with the rationale
  • Drafts the SAR narrative from the pre-filled case data
  • Schedules and works continuing-activity reviews on filed cases
  • Requests information from other teams and records the response

Cannot

  • Approve their own recommendation or their own SAR
  • Export a SAR for BSA E-Filing
  • Change scenarios or thresholds
Approvals
Every filing recommendation and every SAR draft they prepare must be approved by a BSA officer or another designated approver before it leaves the team.
Notified about
New cases assigned to them, recommendations or drafts returned with comments, filing deadlines counted from the date of detection, and continuing-activity reviews coming due.

BSA officer

BSA officer, BSA/AML officer, chief compliance officer, deputy BSA officer

Owns the program: approves filing decisions and SARs, governs detection scenarios and thresholds, and answers to examiners.

Sees

  • Every alert, case and SAR across the institution
  • Program reporting: open work by age, filing deadlines, quality review results
  • Scenario and threshold settings with their tuning history
  • The full audit trail

Does

  • Approves or returns filing recommendations and SAR drafts
  • Exports approved SARs for BSA E-Filing and records the acknowledgment
  • Approves changes to scenarios and thresholds after testing
  • Assigns and reassigns work across teams
  • Decides which roles may see SARs and the fact that one was filed
  • Prepares exam and board reporting

Cannot

  • Approve a SAR they drafted themselves; a second approver is required
  • Edit or delete entries in the audit trail
  • Apply an untested threshold change; the test result must be recorded first
Approvals
Approves SARs, filing and no-file decisions, and scenario and threshold changes; their own drafts need a second designated approver.
Notified about
Recommendations and SARs waiting for approval, filing deadlines at risk, threshold tests completed, and quality review findings.

Quality reviewer

AML quality assurance analyst, BSA QA reviewer, compliance testing analyst

Checks a sample of closed alerts and cases so the program can show its decisions are consistent and well documented.

Sees

  • Samples of closed alerts and cases drawn for review
  • The analyst's or investigator's reasons, notes and evidence
  • Quality review results and where reviewers and analysts disagree

Does

  • Draws review samples by team, scenario or reason code
  • Records whether each decision was supported, with comments
  • Returns an alert or case for rework when the decision was not supported
  • Tracks findings until they are resolved

Cannot

  • Change the original decision or edit the original notes
  • Review their own work
  • Approve or export a SAR
Approvals
Their findings go to the BSA officer, who decides on any rework or follow-up.
Notified about
New review samples, and rework completed on items they returned.

Model and analytics staff

AML model analyst, financial crimes data analyst, model risk analyst

Tunes and documents the detection scenarios and models, keeping the evidence of each test.

Sees

  • Scenario and model logic, thresholds and their history
  • Historical alert volumes and outcomes by scenario
  • Data quality results from incoming files

Does

  • Runs threshold tests against historical data
  • Documents the results and recommends changes
  • Prepares tuning evidence for model validation and examiners
  • Reviews data quality issues with the teams that supply the data

Cannot

  • Apply a scenario or threshold change without BSA officer approval
  • Open, work or close alerts and cases
  • See SAR narratives unless your institution grants that separately
Approvals
Every scenario or threshold change they recommend is approved by the BSA officer before it goes live.
Notified about
Threshold tests completed, data quality failures on incoming files, and decisions on their recommended changes.

Auditor or examiner (read-only)

Internal auditor, external auditor, regulatory examiner (under temporary access)

Reviews the program's decisions and evidence without being able to change anything.

Sees

  • Alerts, cases and SARs within the scope the institution grants
  • Program reports and quality review results
  • Scenario documentation and tuning evidence
  • The audit trail

Does

  • Searches and reads records within their scope
  • Exports records and reports they have been given access to, with each export logged
  • Leaves review notes where the institution enables them

Cannot

  • Change, approve, close or delete anything
  • See records outside the scope and dates granted
  • Keep access after it expires
Approvals
Their access is approved by the BSA officer or an administrator, with a scope and an end date.
Notified about
Nothing by default; access granted and expiring is confirmed to the person who approved it.

Administrator

Application administrator, IT or compliance systems administrator

Manages users, roles and configuration on behalf of the compliance team, without access to the substance of investigations.

Sees

  • Users, roles, teams and queue settings
  • Configuration such as reason codes and assignment rules
  • The record of permission changes

Does

  • Adds and removes users, or maps them from single sign-on groups
  • Assigns roles and teams
  • Maintains reason codes, queues and assignment rules
  • Runs access review reports

Cannot

  • Open alerts, cases or SARs
  • Grant themselves a compliance role without a second administrator or the BSA officer
  • Change scenarios or thresholds
Approvals
Role changes that grant access to SARs are approved by the BSA officer.
Notified about
Access reviews coming due and accounts not used for a period your policy sets.

Permissions at a glance

ActionAnalystInvestigatorBSA officerQA reviewerModel staffAuditorAdmin
Work and close alertsOwn work onlyOwn work onlyFullNo accessNo accessNo accessNo access
Escalate alerts to a caseOwn work onlyOwn work onlyFullNo accessNo accessNo accessNo access
Work cases and add evidenceNo accessOwn work onlyFullNo accessNo accessNo accessNo access
Recommend file or no-fileNo accessOwn work onlyFullNo accessNo accessNo accessNo access
Draft a SARNo accessOwn work onlyFullNo accessNo accessNo accessNo access
Approve a SAR or filing decisionNo accessNo accessApprovesNo accessNo accessNo accessNo access
Export a SAR for BSA E-FilingNo accessNo accessFullNo accessNo accessNo accessNo access
Run threshold testsNo accessNo accessFullNo accessFullNo accessNo access
Change scenarios and thresholdsNo accessNo accessApprovesNo accessNo accessNo accessNo access
Record quality review findingsNo accessNo accessView onlyFullNo accessView onlyNo access
View audit trailNo accessNo accessView onlyView onlyNo accessView onlyView only
Manage users and rolesNo accessNo accessApprovesNo accessNo accessNo accessFull
  • Full
  • Own work only
  • Approves
  • View only
  • No access

How access is controlled

  • Four-eyes rules are built in: nobody approves a SAR, a filing decision or a threshold change that they prepared themselves, and quality reviewers never review their own work.
  • Roles are configured with you during implementation. You can rename them, create custom roles, and limit them by team, branch, business line or region, so a team sees only the work it is responsible for.
  • Every permission change is recorded in the audit trail with who made it and when, and access review reports list each person's roles for periodic certification by the BSA officer.
  • Staff sign in through your identity provider, and roles can follow its groups. Auditors and examiners get temporary read-only access with a defined scope and an end date, rather than shared accounts.

Features

What it does

Explainable alerts

Every alert shows the scenario or model factors that produced it, in words an examiner can follow.

Threshold testing

Test a change to a scenario or threshold against historical data before it goes live, and keep the result as tuning evidence.

Case management

Assignment, due dates, notes, attachments and a four-eyes approval step before any SAR leaves the team.

SAR drafting

Subject, activity, amounts and dates pre-filled from the case, with a narrative template that follows FinCEN's guidance on what a narrative should cover.

Deadlines and continuing activity

Filing deadlines counted from the date of detection, and reminders for continuing-activity reviews on filed cases.

Exam-ready audit trail

Who did what, when and why, for every alert, case and report, exportable for internal audit and examiners.

Customer risk view

Each customer's risk rating, due-diligence data, beneficial owners and alert and case history on one screen.

Scenario library

Detection scenarios for structuring, rapid movement of funds, layering through related accounts, dormant-account activity and profile deviation, each documented with its logic and thresholds.

Alert quality review

Sample closed alerts for second review, record the outcome, and see where analysts disagree.

Section 314 matching

Search customers and transactions against 314(a) request lists and record the result of each search.

Workload management

Queues by team, assignment rules and views of open work by age, so managers can balance the load.

Document management

Supporting documents, research and correspondence stored with the case and retained under your retention schedule.

Integrations

How it connects to your systems

Connects toHowWhat flows
Core banking and paymentsTransactions, accounts and customers by scheduled file transfer or API, mapped during implementation.In: transactions, accounts and customer records on your schedule.
Customer due diligenceCustomer risk ratings and KYC/CIP data from your onboarding system, including Moraph's Digital Member Onboarding.In: risk ratings, identification and beneficial-ownership data.
Sanctions screeningResults from the screening system you already use can be attached to cases.In: screening hits and their dispositions.
Wire and ACH systemsPayment details such as originators, beneficiaries and counterparties, so cases show who sent money to whom.In: wire and ACH details with counterparty information.
BSA E-FilingApproved SARs are exported in the batch format accepted by FinCEN's BSA E-Filing System for your team to submit.Out: SAR batch file. In: filing acknowledgment and BSA ID, recorded by your team.
Single sign-onStaff sign in through your identity provider (SAML or OpenID Connect).In: user identity and group membership for role assignment.
Work APICase and alert data available to your data warehouse and reporting tools through the Moraph Work API.Out: alerts, cases, decisions and status.
Model risk managementScenario and model documentation shared with Moraph's Model Risk Management (MRM) Validator or your own model inventory.Out: scenario versions, thresholds and tuning results.

Each integration is confirmed in discovery and specified in the design. See how an engagement progresses.

Security and privacy

How your data is protected

Single sign-on

Staff sign in through your identity provider, so your password and multi-factor policies apply.

Role-based access

What each person can see and do follows their role; approving a SAR is separate from drafting one.

Restricted SAR information

Access to SARs and the fact that one was filed is limited to the roles you choose, supporting SAR confidentiality.

Encryption and keys

Client data is encrypted, with keys Moraph staff cannot use without explicit, time-bound authorization.

Complete audit trail

Every view, change, decision and export is logged with the person and time, and cannot be edited.

Data residency

Data stays in the hosting region you choose: the United States, the United Kingdom or Australia.

Company-wide controls, independent audits (SOC 2 Type II and ISO/IEC 27001) and data residency are described in our Trust Center, where you can request the evidence pack.

Reporting

What you can report on

12 standard reports, grouped by who uses them. Each shows who it is for, how it can be broken down, how it is delivered and what it is used for. The data behind them is also available to your own reporting tools.

Operational

Open work by age

For team leads and the BSA officer

Every open alert and case with its age, assignee, team and status, sorted so the oldest work is visible first.

Break down by
Team, Analyst or investigator, Scenario, Age band, Status
Delivered as
Live dashboard; CSV export
Used for
Rebalancing workload and making sure no alert or case sits unworked.

SAR deadlines

For investigators and the BSA officer

SARs in draft, awaiting approval and filed, each with its deadline counted from the date of detection and the time remaining.

Break down by
Status, Investigator, Approver, Deadline window, Initial or continuing
Delivered as
Live dashboard; scheduled email; CSV export
Used for
Making sure every report is approved and filed on time.

Continuing-activity reviews

For investigators and the BSA officer

Filed cases with a continuing-activity review due, the activity seen since the last filing, and the outcome of past reviews.

Break down by
Due date, Investigator, Customer risk rating, Outcome
Delivered as
Live dashboard; scheduled email
Used for
Deciding whether to file a continuing-activity report and evidencing that each review took place.

Section 314(a) search log

For bSA officer

Each 314(a) request list searched, when it was searched, by whom, and whether any matches were found and reported.

Break down by
Request list, Search date, Result, User
Delivered as
Live view; CSV and PDF export
Used for
Showing that every 314(a) list was searched and answered as required.

Management and board

Alert volumes and outcomes

For bSA officer, compliance committee and board

Alerts generated, closed and escalated, and the cases and SARs that resulted, by scenario and period.

Break down by
Scenario, Period, Business line, Customer type, Outcome
Delivered as
Live dashboard; PDF for committee packs; CSV export
Used for
Board and committee reporting on how the monitoring program is performing.

Program summary

For senior management and the board

A periodic summary of monitoring activity, filings, overdue work, open quality findings and scenario changes in the period.

Break down by
Period, Business line, Branch or region
Delivered as
PDF; scheduled email
Used for
Giving the board the information it needs to oversee the BSA/AML program.

Team capacity and throughput

For team leads and the BSA officer

Alerts and cases worked per team over time, work received against work closed, and where backlogs are building.

Break down by
Team, Period, Scenario, Work type
Delivered as
Live dashboard; CSV export
Used for
Making the case for staffing and spotting backlogs before they become exam findings.

Regulatory and audit

Scenario and threshold change history

For bSA officer, model risk staff, examiners

Every change to a scenario or threshold, with the threshold test behind it, who proposed and approved it, and when it took effect.

Break down by
Scenario, Change date, Approver, Change type
Delivered as
Live view; PDF and CSV export
Used for
Evidencing that tuning was tested, approved and documented.

Threshold test results

For model and analytics staff, BSA officer

For each threshold test, the alerts the proposed setting would have produced or suppressed against historical data, compared with the current setting.

Break down by
Scenario, Test date, Data period, Proposed value
Delivered as
Live view; PDF and CSV export
Used for
Deciding whether a tuning change should go live, and keeping the evidence of that decision.

Audit trail extract

For internal audit and examiners

Who did what, when and why for a selected alert, case, SAR or period, including notes, decisions and approvals.

Break down by
Record, User, Action, Date range
Delivered as
On request in the product; CSV and PDF export
Used for
Answering examiner and auditor requests for evidence without assembling it by hand.

Quality

Quality review results

For quality reviewers, team leads, BSA officer

Sampled alerts and cases, the reviewer's finding, and where reviewers disagreed with the original decision.

Break down by
Analyst, Scenario, Finding type, Period
Delivered as
Live dashboard; CSV export
Used for
Targeting training and showing that decisions are checked.

Closure reasons

For team leads, BSA officer, model and analytics staff

The reasons recorded when alerts were closed as not suspicious, by scenario, to show where scenarios produce alerts that rarely lead anywhere.

Break down by
Scenario, Closure reason, Analyst, Period
Delivered as
Live dashboard; CSV export
Used for
Pointing scenario tuning at the alerts that cost the most effort for the least value.

Exports, access and evidence

  • Every report can be exported to CSV, and summary and evidence reports to PDF. Reports can be scheduled to arrive by email for the people entitled to see them.
  • Each report can be filtered and the filters saved, so a team lead or the BSA officer can keep their own views. Reports that need a different shape can be built in your own tools from the data described below.
  • Alert, case and SAR data is available through the Moraph Work API, and can be delivered to your data warehouse or business intelligence tool for reporting alongside other risk data.
  • Reports respect each viewer's role: an analyst sees their team's work, the BSA officer sees the whole program, and examiners and auditors can be given read-only access to reports and the audit trail.
  • Regulatory and audit reports can be run as of a past date and give the same result each time. Running and exporting a report is itself recorded in the audit trail.

Deployment

Where and how it runs

Moraph cloud

Hosted and operated by Moraph in the United States region. United Kingdom and Australia regions are available for institutions outside the US.

Dedicated environment

A single-tenant environment for institutions whose policies require isolation, scoped in the proposal.

With a managed service

Optionally run alongside a Moraph managed service for scenario tuning support and platform administration.

Security controls, independent audits and data residency are set out in our Trust Center. Engagement models and what drives a quotation are on Working with Moraph.

Implementation

What a rollout involves

The general phases are on Working with Moraph. For this product, they involve the following.

Data mapping

We map your core, payment and customer data to the Hub's model and agree the file or API schedule. We need data extracts and a contact from your core-system team.

Scenario configuration

Detection scenarios and thresholds are set for your products, customer base and risk assessment, and documented for your model risk process.

Historical testing

Scenarios are run against historical data and the results reviewed with your BSA officer before any threshold is approved.

Workflow and roles

Queues, assignment rules, reason codes, approval steps and roles are configured to match your procedures.

Parallel run

Where you are replacing a monitoring system, both run side by side for a period you choose, and differences in alerts are reviewed.

Training and go-live

Analysts, investigators and approvers are trained on their own workflows, and open cases are migrated or finished in the old system by agreement.

Limitations

What it does not do

Worth knowing before you evaluate it.

  • The Hub does not file reports itself. A person at your institution reviews, approves and submits each SAR through BSA E-Filing.
  • Detection depends on the completeness and quality of the transaction and customer data you provide. Scenarios and thresholds are tuned to your data during implementation and should be reviewed periodically.
  • It is not a sanctions screening engine. It uses results from the screening system you already have.
  • It is designed for US Bank Secrecy Act requirements and FinCEN reporting. Suspicious-activity reporting in other countries is not included.
  • It does not file Currency Transaction Reports or other BSA reports besides SARs.
  • It does not perform customer onboarding or identity verification; it uses the due-diligence data your onboarding process produces.
  • Scenario thresholds and model changes are your institution's decisions; the Hub records and tests them but does not approve them.
  • Real-time blocking of payments is not included; monitoring works on transactions after they are recorded.

Evaluation checklist

What to test in a demonstration or pilot

Questions worth putting to us, and to any other vendor you are considering.

  1. Load a sample of your own anonymized transactions and compare the alerts with those from your current system
  2. Ask an analyst to work an alert from queue to closure and time how many systems they still need
  3. Check that each alert's explanation would satisfy your examiners
  4. Walk through a SAR from case to approved draft and review the narrative structure
  5. Test a threshold change and review the evidence it produces
  6. Confirm role separation: who can draft, approve and export a SAR

Questions

Frequently asked questions

Who owns the data in the Hub?

Your institution does. How it is returned to you and deleted at the end of the agreement is set out in the contract.

Can we use our own detection scenarios?

Yes. The scenario library is a starting point; scenarios and thresholds are configured for your products and risk assessment, and you can add your own logic during implementation.

Does the Hub replace our sanctions screening?

No. It works alongside your screening system and attaches its results to cases.

How is it priced?

As a subscription, usually measured by the size of the institution or the volume of activity monitored, with implementation charged separately. See Working with Moraph for what drives a quotation.

How do examiners see our work?

A read-only examiner role shows alerts, cases, reports, scenario documentation and the audit trail, and everything can be exported.

Is there an accessibility conformance report?

Ask for one through the procurement request form at /how-to-buy/request, naming the version you are evaluating.

Next steps

Evaluate AML & SAR Automation Hub

Book a demonstration

See the product working with sample data, focused on your workflows.

Request a demonstration

Request a technical briefing

Architecture, integrations, security and hosting, with our engineers and your technical team.

Request a briefing

Factsheet

This page on two sides, to share with colleagues or add to your evaluation file.

Open the factsheet

Buying through a formal procurement? See How to buy for purchasing routes, accessibility conformance reports and company information. Documentation: AML & SAR Automation Hub guides on docs.moraph.com (getting started and security guides are public; setup, administration and integration guides are for client accounts). Support: AML & SAR Automation Hub support guide.

Related products