# JPMC-PDP Documentation from https://developer.payments.jpmorgan.com # Core concepts This document explains the core concepts behind the payment holds decisioning service. Understanding these concepts will help you integrate with the API and build effective workflows for reviewing and decisioning payment holds. ## Fraud Screening Engine The Fraud Screening Engine is an advanced system designed to protect your assets and reputation by automatically screening payments for potentially fraudulent activity. Every day, millions of transactions are analyzed, with only a small subset flagged for further review based on risk indicators. While most suspicious transactions can be managed through automated controls and client decisioning, there may be rare cases where certain payments are flagged at higher risk. In these instances, J.P. Morgan may reach out to you directly for additional information to ensure the security of your accounts. Please note that details of these high-risk cases are handled with strict confidentiality. ## Hold Clients initiate payments through any of the bank’s supported channels (J.P. Morgan Access, Host-2-Host, SWIFT, API, etc.). All payments are automatically screened by J.P. Morgan’s fraud screening systems. If a payment is identified as high risk, it is placed on hold. For transactions eligible for bank control decisioning, a notification is sent through API or webhook if integrated; provided notification functionality is enabled. This alert informs users that a payment is awaiting review. ### Bank and client review Some payments may trigger bank-level fraud rules that cannot be decisioned directly by the client. In these cases, J.P. Morgan’s fraud screening systems will place the payment on hold for further review. These transactions are considered higher risk by J.P. Morgan’s fraud operations and are handled with strict confidentiality. For such payments, J.P. Morgan may conduct manual outreach to the client to request additional information or clarification before proceeding. This process ensures an extra layer of protection for your accounts and helps safeguard against sophisticated fraud attempts. For all other transactions eligible for bank control decisioning, authorized users receive notifications via API or webhook, if enabled and can review and act on held payments through the Alerts and Decisioning or their integrated systems. ## Auto-canceled holds Payments that are not decisioned by the specified ‘Time to Decide’ deadline may not be processed on the intended value date. If no action is taken within this timeframe, the payment will be automatically canceled according to the following deadlines: - Wires: 5 business days after the value date. - ACH: 1 business day after the value date. - RTP: 5 business days after the value date. This automatic cancellation helps to reduce the risk of processing outdated or unauthorized transactions. ## Receiving or retrieving holds Your application will allow your users to decision holds. You must obtain a list of holds for your users to review, which you can do by: 1. Receiving holds in near real-time via webhook (recommended) 2. Pulling holds dynamically via API ### Push notification (Webhook) The bank will push holds to your application via webhook using a callback URL that you define. Holds are delivered in near real-time on a best-effort schedule. Notification events are available for both new and updated holds. You register for one or more event types as part of API onboarding. ### Pulling Holds via REST API You can pull holds on demand via REST API. APIs are available to retrieve a list of holds filtered by status, substatus and date range. A separate endpoint is available to retrieve the full details of a single hold by its unique identifier. ## Status and substatus Every hold has both a status and a substatus. The status represents the high-level state of the hold: - PENDING: The payment is being held and must be reviewed by either your users or the bank. - APPROVED: The payment was held but has since been approved and released. - REJECTED: The payment was held and rejected during review, resulting in payment cancellation. The substatus provides additional detail for each status. Specifically, the substatus conveys the actor responsible for changing the status (your users or the bank) and the reason the hold was approved or rejected along with the actor who made that decision. See [API specification](/api/fraud-solutions/alerts-and-decisioning/overview) for more information. ## Decision A decision is the action taken on a payment that is pending review in the Alerts and Decisioning. Decision can be approve or reject a transaction, specifying reasons such as duplicate transaction, incorrect beneficiary information or suspected fraud. If no action is taken, then the payment is subjected to automatic cancellation. In some cases, payments may require additional follow-up by the bank’s fraud operations team, who may confirm fraud, approve, or reject the transaction based on their investigation.