Narmi Guard prevents account takeover and financial loss by integrating real-time device intelligence into log-in and transaction monitoring. Moving beyond standard credentials and MFA—which fraudsters often bypass—Narmi Guard blocks access from high-risk devices and networks (such as those associated with bots, emulators, and device farms) and flags suspicious transactions. This provides a crucial, additional defense layer against sophisticated threats.
Narmi Guard helps your institution shift focus from recovery to prevention in the following ways:
Log-ins are evaluated in real time based on a device risk profile
Device risk is integrated into transaction evaluation (e.g., a new device combined with a large wire = high risk)
Proactive detection using device recognition and risk profiling
Aids in the detection of compromised accounts with a user notification when logging in from a new device
How Device and Log-In Monitoring Works
We partner with Fingerprint, a leading provider of device intelligence and fraud prevention solutions. With Fingerprint, Narmi Guard provides a comprehensive risk assessment and collects extensive data about the connecting device (mobile app or browser). Fingerprint reliably identifies devices with high accuracy and can detect a large range of risk patterns with low latency. Your institution benefits from Fingerprint’s 100+ behavioral and device-based fraud signals to strengthen account security and improve customer trust.
Our monitoring is built on two core components:
Consistent device recognition – The ability to consistently recognize the same device. This is crucial for good users (to establish trust and streamline their experience) and bad actors (to prevent continued access to the platform).
Risk profile – A risk profile is associated with the device, generally simplified into three categories:
The device and log-in risk context is combined with user and transaction context for money movement (ACH, wires, and FedNow). Enhanced rules consider factors like whether the user is connecting from a new device and submitting a high-value transaction (e.g., a $10,000 wire transfer)
Risk Level | Description | Log-In Policy Example |
|---|---|---|
Low | The device is known, and no additional risk is added to the transaction. | Allow log in (requires valid credentials). The device adds no risk to subsequent transaction rules. |
Medium | The device is new for this user (not enough to block alone), but combined with a high-value transaction (e.g., a large transfer), it escalates the risk. | Allow log in, but flag the event. If followed by a large transaction, the combination triggers a review. |
High | The device has been associated with multiple user accounts (suspicious) or has been deny-listed (e.g., a known bot). | Block log in to Narmi Banking (can optionally lock the account). No transaction impact as the user is blocked from accessing the app. |
Integration with Alloy Workflows
Narmi Guard’s device and log-in monitoring features are deeply integrated with your existing Alloy workflows in the following ways:
Workflow location – All device and log-in evaluations are run via Alloy workflows in your account.
Data flow – Narmi receives device data from Fingerprint, integrates it, and sends it to Alloy. This data feeds directly into the Alloy workflow as data points.
Customization – You retain full freedom to customize these workflows, including utilizing specific device attributes, adjusting thresholds, and setting up new rules.
Tags and Rules (Outcome Reasons) – Tags are the output in Alloy that may originate from Fingerprint data (e.g., “VPN is active,” “Proxy”) or Narmi data, and are used to trigger Alloy risk rules (e.g., “R10 High user count for the device”).
Your institution defines and maintains the tags and rules used in Alloy, and we can provide a starting template for you to use.
For more information on Alloy workflows and transaction monitoring, refer to Narmi Guard Transaction Monitoring.
Narmi Guard Implementation
Please contact your Narmi Relationship Manager to implement Narmi Guard at your institution. This requires purchasing the service and an implementation project. It is highly recommended to enable the feature in reporting mode for a period of 30 to 60 days, without actually blocking users. This observation period allows your team to:
Observe the flagged events (e.g., false positives).
Refine and calibrate the rules before going live in decision mode to minimize user frustration.
Build up data for rules reliant on a "known device" (as every device will initially be flagged as new).