Socure Outage History

Started Jun 16, 2026, 07:46 AM UTC· resolved Jun 16, 2026, 08:15 AM UTC

1. resolved Jun 16, 2026, 08:31 AM UTC

   On June 16, 2026, from 03:45 AM to 04:03 AM EDT, RiskOS APIs experienced elevated error rates. The issue is fully resolved and all systems are now operating normally. The degradation occurred during remediation work tied to an networking error alert. A subset of API requests returned 5XX errors during this window, though the service remained partially available throughout. No customer action is required. A full Root Cause Analysis (RCA) will be shared once the investigation concludes.

2. postmortem Jun 19, 2026, 03:40 PM UTC

   **Root Cause Analysis** **Incident:** RiskOS API Services Degradation During NAT Gateway Remediation **Date Range:** 06-16-2026 **Impact:** Intermittent degradation for a subset of API requests **Status:** Recovered ## **1. Summary** On June 16th, 2026, RiskOS API services experienced intermittent degradation for a subset of API requests between **3:46 AM EDT and 4:02 AM EDT**. During this period, some requests failed while network connectivity was being transitioned as part of a controlled remediation. Earlier that day, Socure observed elevated connection error alerts and identified critically high Cloud NAT port utilization in the RiskOS commercial environment. The condition was not impacting existing customer transactions at the time of detection, but it created a significant capacity risk for outbound connectivity if additional workloads restarted, scaled, or deployed. To reduce the risk of broader impact, Socure performed a controlled network remediation during a lower-workload window. The remediation improved capacity handling and reduced shared NAT resource contention across origin IP blocks. During the transition, some existing connections were briefly interrupted and had to be re-established, resulting in intermittent request failures. The remediation activity completed in approximately 5 minutes, and overall recovery and stabilization completed within approximately 15 minutes. No customer action was required after connectivity was restored. ## **2. Timeline** | **June 16th,** **2026 / Time** | **Event** | | --- | --- | | 12:00 AM EDT | The Socure Engineering team observed elevated connection error alerts and began an investigation. No customer transaction impact was identified at this time. | | 12:30 AM EDT | Investigation identified critically high Cloud NAT port utilization, creating a capacity risk for outbound connectivity. SRE confirmed that existing customer transactions were not being impacted at that time. | | 12:30–3:45 AM EDT | The Socure Engineering team evaluated remediation options, assessed the risk of leaving the configuration unchanged, and planned remediation during a lower-workload window to reduce potential customer impact. | | 3:45 AM EDT | The engineering team proceeded with the planned network capacity remediation. | | 3:46 AM EDT | Intermittent request failures began as some existing network connections were briefly interrupted during the transition to the updated configuration. | | 3:52–4:00 AM EDT | Network configuration updates were applied to improve capacity handling and reduce shared NAT resource contention across origin IP blocks. | | 4:02 AM EDT | Intermittent request failures ended after traffic completed transition to the updated configuration and connections were re-established. | | ~4:02 AM EDT | Platform connectivity stabilized. | | ~4:15 AM EDT | Incident considered resolved after validation and monitoring confirmed recovery. | ## **3. Root Cause** **Primary Root Cause:**The incident was caused by critically high Cloud NAT port utilization in the RiskOS commercial environment. The NAT configuration had insufficient available port capacity to provide safe headroom for normal connection churn, workload restarts, scaling activity, or deployments. **Contributing Factors:** * The residual NAT capacity risk was a consequence of emergency recovery activities undertaken after the June 9 RiskOS service outage, where the primary focus was restoring service availability. * NAT port utilization reached approximately 99–100%, creating a significant risk of outbound connectivity degradation. * NAT capacity was shared across origin IP blocks, which increased the likelihood of port exhaustion under workload pressure. * During remediation, some existing connections were reset while traffic transitioned to the updated network configuration, resulting in temporary intermittent request failures. ## **4. Resolution** Socure updated the NAT configuration to improve capacity handling and reduce shared-resource contention across origin IP blocks. The remediation was performed because the existing NAT utilization level presented a significant reliability risk, and delaying the change could have increased the chance of broader service degradation. During the transition, some existing connections were reset and had to be re-established. Once the updated configuration took effect, intermittent request failures stopped and platform connectivity stabilized. No customer action was required after connectivity was restored. Requests retried after recovery were expected to process normally. ## **5. Corrective and Preventive Actions** | **Action** | **Description** | **ETA / Status** | | --- | --- | --- | | Reduce NAT capacity contention | NAT usage was separated to reduce shared capacity risk and limit the blast radius of future NAT capacity issues. | Completed | | Enable dynamic port allocation | Dynamic port allocation was enabled to improve NAT port capacity management and reduce exhaustion risk. | Completed | | Improve NAT utilization monitoring | Add or tune monitoring for NAT port utilization, dropped packets, and connection errors with actionable alert thresholds before utilization reaches critical levels. | Completed | | Move network configuration to Infrastructure as Code | Continue moving RiskOS network configuration into version-controlled Infrastructure as Code to improve reviewability, repeatability, and recovery as a part of AWS Migration. | Planned | ## **6. Lessons Learned** * NAT port utilization should be treated as a critical reliability signal for workloads that depend on outbound connectivity. * NAT capacity should have sufficient headroom for normal connection churn, workload restarts, scaling events, and deployments. * Remediation of high-risk network conditions can still create temporary impact when existing connections are reset, so change planning should include clear validation and communication steps. * Network changes should include pre-change checks for current utilization, available NAT capacity, expected connection reset behavior, and rollback options. * Continued investment in environment isolation, Infrastructure as Code, and stronger monitoring will reduce the likelihood and impact of similar incidents. ## **7. Next Steps & Ongoing Commitment** Socure recognizes that customers rely on RiskOS to be available and reliable. We take accountability for the disruption caused during this remediation and are continuing to improve our network architecture and operational controls. To reduce the likelihood of recurrence, Socure is pursuing the following: 1. **NAT Capacity Controls:** We are improving monitoring and alerting for NAT utilization, connection drops, and port exhaustion risk so that capacity issues can be identified and remediated before they impact customer traffic. 2. **Infrastructure as Code:** We are continuing to move RiskOS network configuration to a version-controlled model so that every change is reviewed, repeatable, and can be recovered quickly. 3. **Environment Isolation:** We are separating network resources and reducing shared capacity dependencies so that the impact of any capacity issue or network change is contained. 4. **Safer Network Operations:** We are strengthening pre-change validation, rollback planning, and maintenance window selection for network changes that may affect customer traffic. 5. **Operational Runbooks:** We are updating operational runbooks for NAT capacity exhaustion and Cloud NAT changes so that response and recovery steps are repeatable and clearly documented.

Read the full incident report →

Started Jun 15, 2026, 04:15 AM UTC· resolved Jun 15, 2026, 05:00 AM UTC

1. resolved Jun 15, 2026, 05:37 AM UTC

   On June 15, 2026, between 12:15 AM and 1:00 AM EDT, the OTP Verification endpoint experienced elevated error rates. The system recovered automatically at 1:00 AM EDT. No action is required from customers. Our investigation confirmed the issue was transient. All systems are operating normally. A Root Cause Analysis (RCA) will be published once our investigation is complete.

2. postmortem Jun 22, 2026, 09:39 PM UTC

   ## **Root Cause Analysis \(RCA\)** **Incident:** Elevated 5XX errors on the OTP Verification endpoint **Date Range:** June 15, 2026 — 12:15 AM ET to 1:00 AM ET **Impact:** Customers calling the Socure OTP Verification endpoint \(otp/send\) on the ID\+ production platform or RiskOS workflows experienced HTTP 5XX errors during the incident window, resulting in failed OTP verifications. The endpoint auto-recovered without manual intervention, and no customer action was required. **Status:** Resolved ### **1. Summary** On June 15, 2026, between approximately 12:15 AM and 1:00 AM ET, Socure’s OTP Verification endpoint \(otp/send\) on the ID\+ production platform experienced an elevated rate of HTTP 5XX errors. OTP requests failed or were degraded during this 45-minute window. The endpoint auto-recovered at 1:00 AM ET with no manual intervention required. A concentrated surge in OTP verification volume placed sustained load on Socure’s OTP service, which coordinates OTP generation, delivery, and verification. The service is configured to scale horizontally, but the additional replicas did not successfully come up during the surge window. The existing instances became saturated and restarted repeatedly under load, and resulted in HTTP 5XX errors for the OTP Verification endpoint during this period. Initial investigation considered upstream messaging-provider behavior as a potential contributor; subsequent log and metric analysis confirmed that vendor-side rate limiting was not a material factor during the window, and identified the internal OTP service scaling failure as the primary cause. The service self-recovered as upstream demand returned to baseline. Socure engineering has identified a set of corrective and preventive actions — described below — to address the underlying scaling behavior, strengthen capacity baselines for elevated traffic events, and improve observability around scaling-related saturation conditions. ### **2. Timeline** | Time \(ET\) | Event | | --- | --- | | 12:15 AM | Elevated HTTP 5XX error rates begin on the OTP Verification endpoint \(otp/send\) in the ID\+ production environment. | | 12:17 AM – 12:28 AM | Initial high-volume burst observed on the OTP Verification endpoint; OTP verification request volume rose sharply, placing concentrated load on the MFA Orchestrator service that coordinates OTP delivery and verification. | | 12:41 AM | Incident formally declared and opened within Socure’s incident management system. On-call engineering paged; incident response team assembled. An investigation bridge was convened and telemetry for the OTP service was reviewed in parallel. | | ~12:45 AM | Initial investigation considered upstream messaging-provider behavior as a potential contributor; no broad vendor outage reported on the public status page. Investigation continued in parallel into the health of Socure-owned services in the OTP path. | | 1:00 AM | Upstream OTP verification request volume subsided; service load on the OTP service returned to capacity, and error rates on the OTP Verification endpoint auto-recovered to normal levels. No manual mitigation was required. | | Post Incident | Incident moved to post-incident review; engineering continued investigation and impact assessment to confirm scope of affected accounts and validate the upstream cause. | | June 16 | Detailed log and metric analysis completed. Primary contributor identified as a horizontal scaling failure in Socure’s OTP service: the configured autoscaling did not produce additional replicas during the surge, the existing instances became saturated, and the majority of the observed errors traced to OTP service response failures. Upstream messaging-provider rate limiting was ruled out as a material factor. Investigation into the underlying autoscaling behavior is ongoing with Site Reliability Engineering. | ### **3. Root Cause** **Primary Root Cause:** A concentrated surge in OTP verification request volume placed a sustained load on Socure’s OTP service — the service responsible for coordinating one-time passcode generation, delivery, and verification. The service is configured to scale horizontally under load. During the surge window, the additional instances did not successfully come up. The existing replicas became saturated and restarted repeatedly under sustained load, and the majority of the HTTP 5XX errors observed traced to response failures during this saturation period. Subsequent log and metric analysis confirmed that upstream messaging-provider rate limiting was not a material factor during the window. The dominant error signature in OTP logs corresponded to internal response-handling failures under load, not to vendor-side throttling. The condition was transient: as upstream OTP request volume returned to baseline, pod load returned to capacity and the OTP Verification endpoint auto-recovered without any change to Socure-owned services or vendor configuration. **Contributing Factors:** * **Horizontal scaling failure:** The service’s configured horizontal autoscaling policy did not produce additional instances during the surge window. Without the headroom of additional instances, the existing instances were unable to sustain throughput, became saturated, and restarted multiple times. Investigation into the underlying cause of the autoscaling failure is ongoing with Site Reliability Engineering. * **Baseline capacity headroom:** The baseline instance count for the OTP service, combined with the time required to bring additional instances online, did not provide sufficient headroom to absorb the observed surge prior to additional capacity becoming available. **Non-contributing Factors:** * **Upstream messaging provider:** Service-level rate limiting from the upstream messaging provider was not a material factor during the incident window. Genuine vendor-side 4XX responses observed in logs were limited in volume — far below the dominant OTP error — and did not drive the customer-visible impact. * **Recent changes or deployments:** No Socure application code, configuration, or release change was associated with the incident window. No broad outage was reported on any third-party dependency’s public status page during this period. ### **4. Resolution** * **Service restoration:** The condition was transient and self-resolved as upstream OTP verification request volume returned to baseline. Load on the OTP service returned to capacity, and error rates on the OTP Verification endpoint returned to normal at approximately 1:00 AM ET on June 15, 2026. No manual mitigation was required. Socure engineering verified recovery through telemetry and continued monitoring through and beyond the incident window. * **Validation and verification:** A post-incident review was conducted to confirm the scope and duration of impact. Detailed log and metric analysis identified the OTP service horizontal scaling failure as the primary contributor and ruled out upstream messaging-provider rate limiting as a material factor. Investigation into the underlying cause of the autoscaling failure is ongoing with Socure’s Site Reliability Engineering team. ### **5. Corrective and Preventive Actions** | # | Action | Priority | Status | | --- | --- | --- | --- | | 1 | Vendor engagement — Confirm with the upstream messaging provider the applicable API rate-limit model and validate the effective limits in force for Socure’s account. | High | In Progress | | 2 | Capacity baseline review — Re-baseline the OTP capacity envelope; revisit the baseline \(pre-scale\) instances count and autoscaling thresholds to ensure sufficient headroom to absorb peak surge traffic prior to additional replicas becoming available. | High | ETA: June 25th | | 3 | OTP autoscaling investigation — Investigate with Site Reliability Engineering the root cause of why the configured horizontal autoscaling did not produce additional replicas during the surge, covering pod scheduling, resource constraints, and node availability. | High | In Progress | | 4 | Capacity planning and forecasting — Establish a recurring process to forecast peak OTP send volume from high-throughput customer programs and pre-coordinate vendor capacity ahead of anticipated traffic events. | Medium | Planned | ### **6. Conclusion** This incident was caused by a horizontal scaling failure in Socure’s OTP service during a brief, concentrated surge in OTP verification traffic. The service’s configured autoscaling policy did not produce additional instances during the surge window, the existing instances became saturated, and the majority of the errors observed traced to OTP service response failures. The condition was transient and self-resolved as upstream traffic subsided. Subsequent investigation ruled out upstream messaging-provider rate limiting as a material factor, and engineering is actively investigating the underlying cause of the autoscaling failure to prevent recurrence. Socure takes accountability for this incident and the impact it had on the affected customers. We remain committed to improving the resilience and maintaining a reliable experience for our customers.

Read the full incident report →

Started Jun 13, 2026, 05:54 PM UTC· resolved Jun 13, 2026, 05:54 PM UTC

1. resolved Jun 13, 2026, 05:54 PM UTC

   Between 1:22 PM and 1:31 PM ET, DocV experienced a latency spike due to an internal node upgrade. During this 9-minute window, some customers may have experienced increased latency or timeout errors. The change was reverted right after the latency spike and DocV performance has returned to normal. We apologize for any inconvenience this may have caused.

Read the full incident report →

Started Jun 11, 2026, 09:37 PM UTC· resolved Jun 11, 2026, 10:38 PM UTC

1. investigating Jun 11, 2026, 09:37 PM UTC

   We are currently investigating an issue causing increased latency and intermittent timeouts on the Transaction Search page within the Admin Dashboard. Our engineering team is actively working to resolve the issue and restore normal performance. API requests and transaction processing are working as expected and are not impacted. We apologize for the inconvenience and appreciate your patience while we work to resolve this issue.

2. identified Jun 11, 2026, 10:06 PM UTC

   API requests and transaction processing remain unaffected. We have identified the root cause of the latency and timeout issues affecting the Transaction Search page and have implemented mitigation measures. Some users may still experience delays in transaction visibility while we continue working toward a full resolution. We apologize for the inconvenience and appreciate your patience.

3. resolved Jun 11, 2026, 10:38 PM UTC

   The issue causing increased latency and intermittent timeouts on the Transaction Search page within the Admin Dashboard has been resolved, and functionality has returned to normal. API requests and transaction processing were not impacted during this incident. We apologize for any inconvenience and appreciate your patience.

Read the full incident report →

Started Jun 09, 2026, 10:24 PM UTC· resolved Jun 10, 2026, 12:11 AM UTC

1. investigating Jun 09, 2026, 10:24 PM UTC

   We are currently investigating a system-wide issue impacting RiskOS. Customers may experience errors, degraded performance, or delays when accessing RiskOS services and workflows. Our engineering teams are actively working to identify the root cause and restore full functionality as quickly as possible. We will provide additional updates as more information becomes available.

2. identified Jun 09, 2026, 11:52 PM UTC

   RiskOS API and real-time processing services have been fully operational for all customers since 07:17 PM ET. - Dashboard functionality, including case listing and search, has been restored for customers. Some customers may experience intermittent delays in seeing new case updates or decision changes reflected in the dashboard. - Webhook deliveries remain impacted for a small subset of customers, and our team is actively working toward a full resolution. We will continue to monitor system health and provide additional updates as we confirm complete service restoration. Thank you for your patience and understanding.

3. resolved Jun 10, 2026, 12:11 AM UTC

   The issue impacting RiskOS has been resolved, and service has returned to normal operation. Customers should no longer experience errors, degraded performance, or delays when accessing RiskOS services and workflows. Our teams have confirmed system stability and will continue to monitor performance closely. We appreciate your patience throughout this incident and apologize for the impact this outage may have had on your operations.

4. postmortem Jun 12, 2026, 09:08 PM UTC

   **Root Cause Analysis** ### **Incident: RiskOS Network Connectivity Loss** **Date Range:** **06-09-2026** **Impact: Sev1** **Status:** Recovered ### **1. Summary** On June 9th, 2026 between 17:59 EST and 20:00 EST, network connectivity for RiskOS was disrupted in our commercial environment, resulting in widespread 5xx errors, limited webhook connection problems, and platform unavailability for multiple customers. The issue was linked to a recent GCP network change, which was reverted after discovery. As network connectivity was impacted, API calls never reached Socure, and so could not be recovered after the incident. Customer retries that happened after connectivity was restored worked as intended. API functionality began recovering around 18:41 EST, with dashboard recovery beginning at 19:10 EST, with full resolution at 20:00 EST. ‌ ### **2. Timeline** ‌ | **June 9th, 2026 / Time \(ET\)** | **Event** | | --- | --- | | 17:59 EST | Cloud Router resource deleted, cascades deletion to RiskOS Sandbox and Production Cloud NAT gateway resources. **IMPACT STARTS** | | 18:06 EST | Alerting and customer escalations are correlated, and the rollback to the prior configuration begins. | | 18:15 EST | First customers report API and dashboard impacts. | | 18:24 EST | First notification about incident posted via the Socure Status page | | 18:26 EST | Cloud NAT resource re-created with existing known-to-customer elastic IPs re-attached to Cloud NAT. Evaluation API functionality restored.**PRIMARY IMPACT RESOLVED** | | 18:41 EST | Identified continuing errors linked to customers who use IP whitelisting, as well as dashboard errors. Continued investigation. | | 19:10 EST | RiskOS production platform is now largely recovered, with API and real-time processing services operating normally for all customers. Troubleshooting continues for services supporting dashboard functionality. | | 19:29 EST | Dashboard functionality, including case listing and search, restored for most users. | | 19:49 EST | It is identified there was a missing rule in NAT configuration segregating traffic to come from specific elastic IPs. Rules configured, last 403 errors begin resolving. **ALL IMPACT RESOLVED** | | 19:52 EST | Updated Status page about progress on the case | | 20:00 EST | RiskOS connectivity issues declared resolved. | | 20:11 EST | Notification sent to customers that issue was fully resolved via Status page | ### **3. Root Cause** * **Primary Root Cause:** Unintentional deletion of Cloud Router in production Google Cloud Platform account caused deletion of Cloud NAT resources for RiskOS Sandbox and Production networks, thereby severing outbound connectivity. * **Contributing Factors:** * Google Cloud configurations are currently manually managed, contributing to higher accidental error rate. * In our existing configuration, the central networking resources are defined with production and sandbox resources, increasing the blast radius of core network modifications. In this case, the change unintentionally impacted production resources. ### **4. Resolution** Socure acted to restore the deleted Cloud NAT resources, as well as re-attaching known elastic IP addresses to network egress to prevent customer action. Additionally, select services \(the backends to our dashboard case listing and search\) were intolerant of network interruption, and required manual restart. ‌ ### **5. Corrective and Preventive Actions** ‌ | **Action** | **Description** | **ETA / Status** | | --- | --- | --- | | Restore Cloud NAT resources. | The Cloud NAT and accompanying cloud router were restored. | Completed | | Refactor network resource configuration | Enforce separation of definitions for production and sandbox resources | Planning. Tentative ETA: July 2026 | | Detect connectivity failure faster | Increase the frequency of our external synthetic probes to detect connectivity loss faster. | In-Progress. ETA: Jun 30, 2026 | | Enable deletion prevention policies in Google Cloud Console | Move to add deletion protection mechanisms on critical resources to prevent unintentional resource modifications. | In-Progress. ETA: Jun 19, 2026 | ### **6. Lessons Learned** * The Cloud NATs which were deleted were unrelated to the scope of the network changes planned in the maintenance. Separating the production configuration and implementing our standard high-scrutiny change process is the highest priority. * Configure resource protection for critical infrastructure components to prevent unintentional changes. * Conduct network operations during non US business hours for more availability of support resources in the event of service impact. * Leverage infrastructure as code for absolute configuration and to ensure resource repeatability, as well as facilitate human review for dangerous operations. ### **7. Next Steps & Ongoing Commitment** Socure knows customers rely on it to be available and accurate, and takes full accountability for this configuration error and the disruption it caused. To ensure this problem does not recur, we are pursuing the following steps: 1. **Resource Protection:** We are adding deletion and change-protection controls to critical network infrastructure so that an accidental change cannot disrupt the platform. 2. **Infrastructure as Code:** We are already moving RiskOS network configuration to a version-controlled model so that every change is reviewed, repeatable, and can be recovered quickly within Socure’s AWS environment. 3. **Environment Isolation:** We are separating workload and core platform network resources so that the impact of any single change is contained. 4. **Safer maintenance windows:** We are scheduling network maintenance during periods with the strongest engineering and support coverage.

Read the full incident report →

Started Jun 04, 2026, 04:28 PM UTC· resolved Jun 04, 2026, 04:28 PM UTC

1. resolved Jun 04, 2026, 04:28 PM UTC

   On June 3, 2026, at 12:50 AM ET, a subset of RiskOS customers experienced degraded functionality affecting evaluation processing, API responses, and portions of the RiskOS user interface. The issue was caused by an internal configuration error that impacted the availability of certain application capabilities. Evaluation processing and API functionality were restored by 5:00 AM ET on June 3, 2026, and case list consistency was fully restored by 5:00 AM ET on June 4, 2026. We are actively implementing additional validation controls and monitoring enhancements to help prevent similar incidents in the future. We sincerely apologize for the disruption and appreciate your patience while we worked to resolve the issue.

Read the full incident report →

Started May 23, 2026, 05:36 AM UTC· resolved May 23, 2026, 05:36 AM UTC

1. resolved May 23, 2026, 05:36 AM UTC

   On May 23nd, 2026 between 12:20 AM ET and 1:12 AM ET, we observed 5xx errors returned by the EmailAuthScore endpoint for the DocV module. Minimal transaction failures occurred during this time. Errors have completely subsided and our team will share an RCA after analysis.

Read the full incident report →

Started May 20, 2026, 03:50 PM UTC· resolved May 20, 2026, 04:39 PM UTC

1. investigating May 20, 2026, 03:50 PM UTC

   We are currently experiencing temporary SMS delivery delays for a small subset of users, which may require retrying verification attempts. The team is actively working to mitigate impact while monitoring the issue closely. No customer data or systems have been impacted.

2. resolved May 20, 2026, 04:39 PM UTC

   The issue affecting DocV SMS delivery has been resolved. End users should now receive DocV SMS messages as expected.

3. postmortem May 28, 2026, 06:28 PM UTC

   # **Root Cause Analysis** Report on Socure High SMS Handoff Failure Rate in DocV V5 May 20, 2026 ## **Summary** On May 20, 2026, starting at approximately 9:05 AM ET, Socure's Document Verification \(DocV\) V5 service experienced a significant increase in SMS handoff failures in the commercial production environment. End users were unable to receive SMS verification links. The issue was caused by the exhaustion of Socure's AWS End User Messaging monthly SMS sending budget, triggered by an abnormal volume of international SMS traffic. Socure applied account-level rate limiting, restricted international SMS delivery, and engaged AWS Support to expedite a budget increase. The incident was fully resolved at 12:15 PM ET on May 20, 2026. ## **Timeline** First Alert: May 20, 2026, 9:05 AM ET Issue Initially Contained: May 20, 2026, 9:20 AM ET Issue Resurfaced: May 20, 2026, 10:44 AM ET Issue Fully Resolved: May 20, 2026, 12:15 PM ET **Customer Impact Duration:** ~1 hour 46 minutes **Total Incident Lifecycle:** ~3 hours 10 minutes ## **Description of Incident** On May 20, 2026, at 9:05 AM ET, Socure's monitoring detected an elevated SMS handoff failure rate in DocV V5 for the commercial production environment. Investigation revealed that the AWS End User Messaging monthly SMS sending budget had been exhausted, driven by an abnormal volume of international SMS traffic originating from a single account. Once the monthly budget limit was reached, AWS End User Messaging blocked all outbound SMS delivery from the account. Failures were permanent — messages were not retried once the limit was hit. ## **Impact** * 100% of SMS handoff attempts failed during the peak impact window * Affected customers' end users were unable to receive SMS verification links via DocV Socure immediately applied account-level rate limiting to reduce ongoing spend and requested an emergency budget increase from AWS. International SMS delivery to the top destination countries was also blocked to halt the spend burn while the root cause was addressed. AWS Support was formally engaged with details on traffic patterns and user opt-in flows. Socure published a status page communication to notify customers of the SMS delivery delays and ongoing mitigation efforts. The source of the abnormal traffic ceased sending, and the incident was fully resolved at 12:15 PM ET on May 20, 2026. ## **Resolution** Socure applied account-level rate limiting and blocked international SMS to some destination countries where we noticed unusual delivery pattern to immediately reduce the rate of budget consumption. AWS Support was engaged to expedite an increase to the monthly SMS sending budget. Once the abnormal traffic was stopped and the budget constraints were addressed, SMS delivery was restored. The incident was confirmed fully resolved at 12:15 PM ET on May 21, 2026. ## **Mitigation Plan** These measures are aimed at improving SMS delivery resilience and preventing similar incidents from affecting production environments in the future. _We are committed to transparency, timely remediation, and making the necessary improvements to prevent recurrence._

Read the full incident report →

Started May 11, 2026, 07:35 PM UTC· resolved May 12, 2026, 12:12 AM UTC

1. investigating May 11, 2026, 07:35 PM UTC

   We are aware of an issue that caused latency and intermittent 5xx errors that affected a small subset of DocV transactions that call Image Alert List. The team is looking into solutions to prevent this from recurring.

2. resolved May 12, 2026, 12:12 AM UTC

   Our team has applied a fix to prevent any recurrence of latency and intermittent 5xx errors for DocV transactions calling Image Alert List. We appreciate your patience as our team worked through this issue.

Read the full incident report →

Started May 08, 2026, 12:06 AM UTC· resolved May 08, 2026, 06:17 PM UTC

1. investigating May 08, 2026, 12:06 AM UTC

   We are currently investigating reports of intermittent errors and performance degradation across several platform modules. Users may experience 5xx error messages. Our engineering team is actively diagnosing the root cause and is working to restore full functionality as quickly as possible.

2. identified May 08, 2026, 02:10 AM UTC

   We are actively working in close partnership with AWS to address the underlying issues currently impacting system performance. Users may still experience 5xx error messages as we work towards a solution to restore full functionality.

3. monitoring May 08, 2026, 03:01 AM UTC

   We are pleased to inform that all our services are operating normally. We are currently monitoring our services in partnership with AWS.

4. resolved May 08, 2026, 06:17 PM UTC

   Socure services have now fully recovered and are operating normally. System latency and performance metrics have returned to expected levels. Our engineering and operations teams will continue to work closely with AWS to conduct a comprehensive root cause analysis (RCA) of the incident. We will share the RCA publicly within the next few days once this review is complete.

Read the full incident report →

Started Apr 21, 2026, 11:17 PM UTC· resolved Apr 21, 2026, 11:27 PM UTC

1. identified Apr 21, 2026, 11:17 PM UTC

   DocV mobile app users may experience an issue where the app becomes stuck on a loading spinner during launch within the web view, preventing access. This only impacts certain users, specifically those using app configurations that rely on a web view. Our team is actively investigating and will provide updates as more information becomes available.

2. monitoring Apr 21, 2026, 11:22 PM UTC

   Our team has implemented a fix and is actively monitoring its performance to ensure the issue is fully resolved.

3. resolved Apr 21, 2026, 11:27 PM UTC

   The issue has been resolved and services are now operating normally. Thank you for your patience while our team worked to address this.

Read the full incident report →

Started Apr 14, 2026, 08:23 PM UTC· resolved Apr 14, 2026, 08:23 PM UTC

1. resolved Apr 14, 2026, 08:23 PM UTC

   On April 14th, 2026 we observed issues with displaying transactions calling the First Party Fraud module in the ID+ platform. No transactions failed during this time but some users would have seen a blank screen when reviewing the transaction details in the dashboard. Our team quickly identified the root cause and worked out a fix to mitigate this problem, restoring normal functionality as of 4:00PM ET.

Read the full incident report →

Started Apr 13, 2026, 12:36 PM UTC· resolved Apr 13, 2026, 02:35 PM UTC

1. identified Apr 13, 2026, 12:36 PM UTC

   We’re currently seeing that RiskOS dashboards for some customer accounts are not loading. This is due to maintenance on the vendor side taking longer than expected. We are actively working with the vendor to restore the visualizations as soon as possible. We apologize for the inconvenience and appreciate your patience while we work to resolve this.

2. identified Apr 13, 2026, 02:04 PM UTC

   We apologize for the continued interruption to the dashboard visualizations and are actively working with vendor to restore full service as quickly as possible. There is no impact to evaluation APIs or other core platform functionalities, which continue to operate normally. We’ll continue to share updates as we make progress. Thank you for your patience.

3. resolved Apr 13, 2026, 02:35 PM UTC

   The issue has now been resolved, and services have been fully restored. We appreciate your patience and understanding while we worked through this. If you notice anything unexpected or have any further questions, please don’t hesitate to reach out.

Read the full incident report →

Started Mar 22, 2026, 09:07 AM UTC· resolved Mar 22, 2026, 10:50 AM UTC

1. identified Mar 22, 2026, 09:07 AM UTC

   We are currently observing intermittent timeouts impacting eCBSV requests. Our team is actively investigating. We sincerely apologize for the inconvenience and will share further updates as they become available.

2. identified Mar 22, 2026, 09:53 AM UTC

   We are still observing intermittent timeouts impacting eCBSV requests, and our team is actively investigating the issue. We sincerely apologize for the inconvenience and will continue to share updates as they become available. In the meantime, we truly appreciate your patience.

3. identified Mar 22, 2026, 10:25 AM UTC

   We continue to observe intermittent timeouts affecting eCBSV requests. The root cause has been identified, and remediation efforts are currently in progress. We’ll share further updates as we make progress toward resolution.

4. resolved Mar 22, 2026, 10:50 AM UTC

   We’re pleased to inform you that the required deployments have been successfully completed on our end, and the issue is now resolved. We are currently working closely with our vendor to compile a detailed root cause analysis, which will be shared with you in the coming days.

Read the full incident report →

Started Mar 22, 2026, 06:43 AM UTC· resolved Mar 22, 2026, 07:45 AM UTC

1. investigating Mar 22, 2026, 06:43 AM UTC

   We are currently observing errors impacting eCBSV following SSA’s recent maintenance window from 9:00 PM ET on Saturday, March 21, 2026, through 1:00 AM ET on Sunday, March 22, 2026. We continue to see the usual maintenance-window error indicating that the SSA service is unavailable due to planned maintenance, and we are actively coordinating with SSA to better understand the situation. We will provide additional updates as soon as they are available.

2. resolved Mar 22, 2026, 07:45 AM UTC

   We have not seen the eCBSV error for the past 30 minutes, and the unavailability issue appears to have auto-resolved on SSA’s end. We will follow up with SSA to better understand what led to this unavailability extending beyond the planned maintenance window. We sincerely apologize for any inconvenience caused.

Read the full incident report →

Started Mar 21, 2026, 10:09 PM UTC· resolved Mar 21, 2026, 10:09 PM UTC

1. resolved Mar 21, 2026, 10:09 PM UTC

   On March 21st, 2026 between 1:30 PM ET and 5:50 PM ET, we observed latency degradation in the ID+ platform. No transaction failures occurred during this time. Mitigation has been applied, and latency has since returned to normal levels. Investigation is ongoing to prevent recurrence.

Read the full incident report →

Started Mar 20, 2026, 07:15 PM UTC· resolved Mar 20, 2026, 07:54 PM UTC

1. investigating Mar 20, 2026, 07:15 PM UTC

   We are experiencing an issue causing elevated 5xx errors impacting Device Ingestion Services. Our team is actively investigating and we will continue to provide updates on this incident.

2. resolved Mar 20, 2026, 07:54 PM UTC

   We have mitigated the issue affecting our Device Ingestion Services and traffic has returned to normal. Our team is continuing to monitor the situation and will provide an RCA as soon as possible.

3. postmortem Mar 24, 2026, 04:40 PM UTC

   **Root Cause Analysis:** **Incident:** Elevated 5xx errors in Device Ingestion Services **Date Range:** March 20, 2026 between 2:45 PM ET and 3:43 PM ET **Impact:** All Device and Digital Intelligence SDK traffic was affected. **Status:** Resolved ### **Summary** On March 20, 2026, between 2:45 PM ET and 3:43 PM ET, Socure's Device Ingestion service experienced approximately 58 minutes of unavailability. The incident was triggered by a sudden, significant surge in end-user app activity that revealed a gap in our traffic handling capacity and caused our ingestion service to become unavailable. We tried scaling up our services but the sustained pressure prevented new instances from remaining healthy. We had to temporarily pause ingress traffic to allow the service to stabilize. During this down time, the service stopped returning session tokens and as a result the SDK did not return tokens back to the customer. ### **Timeline** | **Date / Time \(ET\)** | **Event** | | --- | --- | | 2:45 PM ET | Unexpected traffic surge begins, device ingestion service becomes unavailable | | 2:50 PM ET | Team attempts to scale up the service, new instances are unable to remain healthy under sustained load | | ~3:00 PM ET | Incident call initiated, on-call team begins investigation | | ~3:10 PM ET | Team identifies the surge in traffic using ingress log analysis | | 3:21 PM ET | Inbound traffic temporarily paused to allow service recovery | | 3:39 PM ET | Inbound traffic restored | | 3:43 PM ET | Service stabilizes and status page updated to resolved | ### **Description of Incident** The device ingestion service is designed to accommodate typical traffic spikes, but the volume observed in this case significantly exceeded anticipated levels. The device ingestion service was unable to absorb this sudden load. New service instances, upon becoming available, were immediately overwhelmed before they could fully initialize, creating a cycle that outpaced the service's automatic scaling mechanism. This resulted in elevated error rates across device and digital intelligence services, preventing customers from generating new device session tokens during the outage window. It is worth noting that this incident was caused by a legitimate traffic surge from end-user activity. No software deployments or configuration changes were associated with the incident. ### **Resolution** The team temporarily paused inbound traffic to the device ingestion service, allowing a scaled set of service instances which were provisioned with increased resources to initialize successfully. Traffic was restored at 3:39 PM ET and stabilized within minutes. The incident was declared resolved at 3:43 PM ET. Elevated resource settings were retained through the following weekend to accommodate continued elevated traffic. ### **Mitigation Plan** 1. Improve traffic forecasting and capacity planning in collaboration with customers, so that anticipated high-traffic periods are accounted for in advance and the service is scaled accordingly. 2. Implement service-level load shedding effectively so that the ingestion service can continue to handle traffic gracefully under high load while additional capacity is being provisioned. 3. Implement per-customer rate limiting so that a traffic surge from one or more customers does not affect the availability of the shared service. 4. Reduce service instance startup and readiness times so that additional capacity can be brought online more quickly during scaling events. 5. Improve alerting and monitoring at the service ingress layer to notify the team earlier when traffic surges are detected. ### **Commitment** Socure takes full accountability for this incident and the impact it had on our customers. We are implementing rate limiting and per customer traffic controls at the device ingestion layer to ensure that another situation like this cannot affect the availability of the shared service, and we remain committed to delivering the reliability our customers depend on.

Read the full incident report →

Started Mar 20, 2026, 05:30 PM UTC· resolved Mar 20, 2026, 05:50 PM UTC

1. resolved Mar 20, 2026, 06:59 PM UTC

   We experienced an issue that caused elevated 5xx errors impacting request for watchlist screening between 12:19 PM EDT until 1:50 PM EDT. (Only impacted Watchlist plus and Watchlist premier).

Read the full incident report →

Started Mar 12, 2026, 04:15 PM UTC· resolved Mar 12, 2026, 04:37 PM UTC

1. investigating Mar 12, 2026, 04:15 PM UTC

   We are investigating an increase in latency in the International Phone Risk Score module.

2. investigating Mar 12, 2026, 04:36 PM UTC

   We are continuing to investigate this issue.

3. resolved Mar 12, 2026, 04:37 PM UTC

   This issue has been resolved as of 12:19 PM EDT.

Read the full incident report →

Started Mar 10, 2026, 10:00 PM UTC· resolved Mar 10, 2026, 10:00 PM UTC

1. resolved Mar 10, 2026, 10:00 PM UTC

   On March 10th, 2026 between 4:53 PM - 5:03 PM (ET), the RiskOS platform experienced a temporary spike in HTTP 4xx (including 409 conflicts) and 5xx errors across RiskOS APIs. The errors were driven by elevated latency, which resulted in request timeouts and retries. The issue has now been fully resolved. Our team is conducting a root cause analysis and will share a detailed update as soon as it is available. We apologize for any inconvenience this may have caused and appreciate your patience.

2. postmortem Mar 13, 2026, 09:13 PM UTC

   **Root Cause Analysis** **Date:** March 10, 2026 ## **Summary** On March 10, 2026, between **4:53 PM and 5:03 PM ET**, RiskOS experienced a brief service degradation impacting the Evaluation APIs. During a period of concentrated peak request volume, a high-traffic database table reached a performance scaling threshold. Over the past six months, organic growth in the metadata table increased the computational effort required to process certain requests. This growth, combined with a sudden burst in concurrency, led to temporary database CPU saturation. The incident followed an **automated recovery path** as the system cleared the request backlog once peak concurrency levels normalized. Following the recovery, Socure Engineering implemented **architectural hardening** measures to the data access layer, achieving a **99% reduction in latency** for the query pattern that contributed to the incident, ensuring the platform can accommodate future growth without recurrence. ### **Timeline** | **Time \(ET\)** | **Event** | | --- | --- | | **04:53 PM** | Elevated latency and degraded availability began affecting the RiskOS Evaluation APIs. | | **04:54 PM** | Automated monitoring triggered alerts for increased 4xx/5xx response codes. The on-call engineering team was paged and began investigating. | | **04:55 PM** | A second alert for increased API latency was triggered. | | **04:59 PM** | A database monitoring alert was triggered, indicating a sudden spike in CPU utilization on the datastore. | | **05:00 PM – 05:03 PM** | The CPU alert helped the team isolate the problematic query pattern within the Evaluation PATCH endpoint. As the burst of requests causing the degradation subsided, API latency and error rates started to return to normal. | | **05:03 PM** | System performance fully stabilized. The Evaluation APIs resumed normal operation without further elevated error rates or latency. The incident was closed, and a post-incident review was initiated. | ### **Impact** During the ~10-minute window: * **Elevated latency** for Evaluation API requests. * **Increased 4xx and 5xx error responses.** * **Intermittent request failures** as the system prioritized resource stability. Approximately **two-thirds** of evaluation requests completed successfully during the incident window. The remainder returned client/server errors or timed out due to the database reaching temporary saturation limits. Performance stabilized and systems returned to normal operating levels automatically as the traffic burst abated. ### **Root Cause** **Primary Root Cause:** A performance scaling threshold was reached for Evaluation PATCH endpoint due to high latencies on an underlying dataset. As the underlying dataset grew organically, a specific query pattern, previously efficient, became computationally expensive. When met with a concentrated peak in concurrent request volume, the database CPU reached saturation, leading to elevated API latency and timeouts. **Contributing Factors:** * **Dataset Growth:** As the dataset grew over time, the existing query pattern became more expensive to execute, reducing the system’s performance headroom during traffic spikes. * **Concurrency Intensity:** A sustained surge in evaluation request volume acted as a catalyst, surfacing the efficiency bottleneck that was otherwise unobservable during standard traffic levels. * **Retry Amplification:** Standard automated retry behavior during the initial slowdown increased the total request volume, further compounding the pressure on database resources. **Non-contributing Factors:** * **Infrastructure Availability:** There was no evidence of underlying infrastructure failure, hardware downtime, or regional cloud outages. * **Rate-Limit Configuration:** The incident was not caused by a breach of configured rate limits; traffic remained within the platform’s aggregate capacity boundaries. ### **Resolution** The incident followed an **automated recovery path**. As the concurrency burst subsided, the database successfully cleared the request backlog, and API performance returned to standard operating levels without manual intervention. Following the stabilization, Socure Engineering conducted a performance audit and implemented the following **system hardening** measures to prevent a recurrence: * **Query Pattern Optimization:** Deployed a targeted indexing strategy to align the database execution plan with current data volumes. This achieved a **99% reduction in latency** for the query pattern that contributed to the incident. * **Storage Efficiency Maintenance:** Executed a comprehensive cleanup of the high-traffic datasets to minimize I/O overhead and maximize available CPU headroom for future traffic bursts. * **Performance Validation:** Confirmed with simulated sustained surge that the Evaluation APIs are performing consistently within standard operating thresholds and that the specific data access bottleneck has been resolved. ### **Corrective and Preventive Actions** | **Action** | **Description** | **Status/ ETA** | | --- | --- | --- | | **Database Capacity Guardrails** | Strengthen database monitoring to detect "cost-per-query" trends earlier, before they impact API latency. | Completed on March 11th | | **Load Distribution Enhancements** | Conduct a full efficiency audit of all high-growth datasets to ensure data access remains optimized | Completed on March 11th | | **Enhanced Query Controls** | Refine query timeout settings to prevent unnecessary request amplification during short-lived performance slowdowns. | In-Progress / Target ETA: March 20th | ### **Next Steps & Ongoing Commitment** Socure takes accountability for the Evaluation API degradation on March 10. Maintaining consistent, reliable API performance as our customers scale is our top priority. We have successfully optimized the identified data access paths and are strengthening our monitoring and query controls to further improve system resilience. The Evaluation APIs are performing within normal thresholds, and we remain committed to ensuring the platform is equipped for continued growth.

Read the full incident report →

Started Feb 25, 2026, 03:30 PM UTC· resolved Feb 25, 2026, 05:08 PM UTC

1. investigating Feb 25, 2026, 05:06 PM UTC

   Between approximately 10:30 AM and 11:26 AM EST on February 25th, all users of the Web Capture App were likely impacted by “session expired” errors when accessing existing capture links. The issue has been fully resolved, and existing capture application links and new links are now functioning as expected. This only affected Web Capture App and not our native IOS/Android SDKs.

2. investigating Feb 25, 2026, 05:07 PM UTC

   We are continuing to investigate this issue.

3. resolved Feb 25, 2026, 05:08 PM UTC

   This incident has been resolved.

4. postmortem Mar 02, 2026, 05:19 PM UTC

   **Root Cause Analysis:** **Incident: DocV Capture App Production Environment Mismatch \(DR Build\)** **Date Range:** February 25, 2026 **Impact: 35% error rate; Production Capture App served DR endpoints, causing "Session Expired" errors due to CSP blocks.** **Summary:** On February 25, 2026, between 10:34 AM EST and 12:26 PM EST, the DocV Capture App experienced a service degradation where **35% of sessions failed.** The incident was triggered when a build intended for a Disaster Recovery \(DR\) test was uploaded to a DR S3 bucket. An undocumented replication rule automatically propagated this DR configuration into the Production S3 bucket. Consequently, the production application attempted to communicate with DR endpoints, which were blocked by the Production Content Security Policy \(CSP\), resulting in "Session Expired" errors for end users. **Timeline:** | **Date / Time \(ET\)** | **Event** | | --- | --- | | 09:58 AM | DR-specific build published to DR S3 bucket \(PLT-6791\). | | **10:34 AM** | **Start of Incident:** Manual update of `index.html` in DR bucket triggers replication to Production bucket. | | 11:06 AM | BrowserStack automated tests fail \(results posted to a private Slack channel; no alert triggered\). | | **11:26 AM** | **Deployed Capture App fix**. Fixes issues for over 99% customers. | | 12:56 PM | **Complete Restoration confirmed by all impacted customers** | **3. Root Cause** * **Primary Root Cause:** An active, undocumented S3 replication rule existed between the DR bucket and the Production bucket. This caused non-production artifacts to overwrite production files automatically. * **Contributing Factors:** * **Security Policy Enforcement:** As a security best practice, the Capture App utilizes a **Content Security Policy \(CSP\)**. Because the production application was served with DR instructions, the CSP correctly identified a mismatch and blocked the connection attempts. While this prevented data from being sent to the wrong environment, it resulted in the "Session Expired" error experienced by users. * **Non-contributing Factors:** * **Core Application Logic:** The underlying source code for the Capture App was verified as stable; the issue was strictly isolated to build replication to the production environment. * **Backend Services:** All Socure backend APIs remained healthy and operational throughout the incident; the disruption was limited to the front-end to backend api call. **4. Resolution** The resolution involved disabling the automatic replication rule and redeploying the verified build to the production environment. Subsequently, a global invalidation of CloudFront caches was performed to ensure all edge locations were updated. **5. Corrective and Preventive Actions** | **Action** | **Description** | **ETA / Status** | | --- | --- | --- | | Disable Replication | Review and remove unauthorized S3 replication rules between DR and Prod. | **Done** | | Monitoring | Implement Application Performance Monitoring \(APM\) spike monitors for `source:csp-report` logs to detect any bad CSP changes immediately. Add alerts for "Session Expired" error spikes in our monitoring platform and application level Increase the frequency of our synthetic automated tests and add new Alerts on tests failures | March 13, 2026 | | Infra Cleanup | Conduct a comprehensive audit of all S3 bucket policies and cross-region replication rules Add guardrail to our DR environment deployments and refine our rollback procedures to ensure more rapid service restoration. | March 27, 2026 | **6. Lessons Learned** * **Infrastructure Awareness:** Cross-bucket dependencies must be known. * **Proactive vs. Reactive:** Internal synthetic testing \(BrowserStack\) caught the issue, but it was not run immediately after the release, and those automation failures did not automatically create an incident page for the on-call team. * **Inventory Management:** We will refine our rollback procedures to ensure more rapid service restoration. **7. Next Steps & Ongoing Commitment** Socure takes full accountability for this configuration error. To prevent recurrence, we are conducting a comprehensive audit of all S3 bucket policies and cross-region replication rules. Furthermore, we are integrating CSP violation telemetry into our core alerting suite to ensure that any environment mismatch is identified and remediated before it impacts the customer experience.

Read the full incident report →

Started Feb 04, 2026, 05:19 AM UTC· resolved Feb 04, 2026, 05:34 AM UTC

1. resolved Feb 05, 2026, 05:57 AM UTC

   On Feb 5, 2026 approximately 00:19 to 00:34 AM EST. A brief disruption for 15 minutes was noticed in our Watchlist services. Apologies for the inconvenience. All Socure services are fully operational at this time. We are investigating the root cause.

Read the full incident report →

Started Jan 30, 2026, 10:19 PM UTC· resolved Jan 30, 2026, 10:51 PM UTC

1. identified Jan 30, 2026, 10:19 PM UTC

   We have identified an issue affecting the V10.1 version of our Email Risk model that is causing elevated scores. Our technical team has identified the root cause and is actively working on a fix.

2. resolved Jan 30, 2026, 10:51 PM UTC

   The issue has been resolved and model scores have returned back to normal. Our technical team is continuing to monitor these services and will provide a root cause analysis once complete.

Read the full incident report →

Started Jan 30, 2026, 08:33 AM UTC· resolved Jan 30, 2026, 09:25 AM UTC

1. investigating Jan 30, 2026, 08:33 AM UTC

   Starting approximately at 11:30PM ET, Jan 29 we are experiencing instability on the device ingestion service and our engineering team is investigating the issue. You may experience issue in digital intelligence and device risk module. We will update as soon as we have more update.

2. identified Jan 30, 2026, 09:03 AM UTC

   The issue has been identified and a fix is being implemented.

3. resolved Jan 30, 2026, 09:25 AM UTC

   The incident is now resolved. We will follow up with the RCA once it is completed.

Read the full incident report →

Started Jan 26, 2026, 02:54 PM UTC· resolved Jan 26, 2026, 06:40 PM UTC

1. resolved Jan 26, 2026, 05:08 PM UTC

   On Wednesday January 21st, the DEA website experienced a technical issue where a number of the entities listed on their United States Drug Enforcement Agency Fugitives list no longer appeared on their website. On Wednesday, Jan 21 at 9:54 AM EST, our data ingestion system interpreted this failure to retrieve these entities as entity deletions, and as a result monitoring alerts were triggered to your system indicating that these entities were removed. By Wednesday, January 21 at 1:40 PM EST, we restored the incorrectly deleted entities in our database, after which the data was fully available again. Additional corrective monitoring alerts were triggered for entities that were added back as part of the data correction. During this period of time, any entities who are screened but not monitored against this list may have incorrectly not received a match against the United States Drug Enforcement Agency Fugitives list.

Read the full incident report →