Contact Us
Go Back
April 19, 2026
9 min read

Coordinated Timing Patterns That Reveal Collusion

Diagram showing interconnected people and devices, a bank, and a credit card, alongside line graphs labeled T1, T2, T3, illustrating timing patterns. Text reads: Coordinated Timing Patterns That Reveal Collusion.

Coordinated Timing Patterns That Reveal Collusion

A busy day can look normal. Lots of payments, lots of movement, lots of noise. Coordination hides inside that noise because it is spread across different people, counterparties and time windows, so no single record looks decisive.

The signal for possible financial crime shows up when timing repeats across connected activity, linked through shared accounts, shared counterparties, shared identifiers, or repeated routing steps. The same sequence appears again. The same intermediary shows up at the same point in the flow. Small indicators line up inside the same connected group, in the same window, often with the same routing choices.

Graph analysis helps because it surfaces these connections. Instead of implying intent via black box methods that produce a risk score, the workflow can show what connected, what repeated, and the path that ties the activity together, so the timing pattern is reviewable rather than speculative.

Key takeaways

  • Coordinated behavior becomes clearer when timing is evaluated across connected entities, meaning accounts and parties, not one account at a time.
  • Synchronized bursts and repeated sequences carry more weight when they recur inside the same connected group.
  • Collusion timing patterns are easiest to review when the workflow can return the connecting paths, or connection chains, that explain what was connected and why.

Why Collusion Timing Hides in Plain Sight

Most monitoring workflows are optimized for single-entity review. They answer questions like “What did this account do this week?” or “Did this transaction exceed a threshold?”

Coordination rarely cooperates with that structure. It spreads activity across multiple entities, so each piece looks ordinary on its own. The pattern emerges only when you compare timing across relationships.

This is why collusion timing tends to look like noise until you connect it. The behavior is not abnormal in isolation. The repetition and alignment across a connected group are what matter.

The next step is to define which connections matter and then look for timing repetition across those connections.

Coordinated timing signals that matter

These signals do not prove wrongdoing. They support prioritization and investigation when they repeat in a connected context.

Each example below focuses on what a reviewer can verify in the data.

Synchronized bursts across connected entities
A burst becomes more meaningful when multiple linked entities spike in activity in the same narrow window, especially when the activity routes through shared counterparties, shared infrastructure (identifiers such as devices, addresses, or phone numbers), or the same intermediaries.

Example: A set of accounts that share a device or address all show sudden activity within hours of each other, and the funds move through the same intermediary before dispersing.

Repeated sequences that keep the same shape
Some coordinated behavior repeats as a sequence. The order matters. A recurring pattern, such as funding, rapid movement, and reuse of the same routing step, can signal coordination when it repeats across linked entities.

Example: Across several connected accounts, deposits appear, followed by transfers within a similar time window, and the transfers repeatedly pass through the same intermediary account.

Weak-signal alignment inside one connected group
Small indicators that are explainable on their own become more meaningful when they reinforce each other inside the same connected neighborhood or group. The signal is its consistency inside a group, not the severity of any one event.

Example: Each account shows only one mild indicator. When connected, the group shows synchronized timing, shared beneficiaries, and repeated reuse of the same routing path.

What Graph Adds

Graph analysis improves coordinated timing reviews by letting AML programs evaluate timing in context and keep the results reviewable.

It supports three practical capabilities:

  1. It makes connected comparisons possible. Teams can ask whether timing is isolated to one entity or shared across a connected neighborhood in the same window.
  2. It makes repeated structures visible. Coordination often repeats as the same sequence through the same intermediaries. Graph workflows make that repetition easier to validate.
  3. It keeps the explanation intact. Reviewers can see which entities were connected, how they were connected, and which paths drove the escalation decision.

How to Model Coordinated Timing so it Stays Reviewable

Coordinated timing analysis works best when your workflow can connect activity, compare it in the same window, and preserve the rationale.

Focus on these basics:

  • Keep timestamps consistent across sources. If time is unreliable, the workflow will manufacture patterns you cannot defend.
  • Capture relationship context that links activity. Accounts, people, businesses, counterparties, devices, addresses and routing intermediaries should be connectable as data, not buried in notes.
  • Use explicit time windows. Define the window you are analyzing and apply it consistently across the entity and its connected neighborhood.
  • Use a scoring system that is parameterized so it can easily be revised and maintained. Scoring and alerts should always show the underlying connections and the timing pattern that triggered review.

How TigerGraph Fits

Coordinated timing reviews break down when teams cannot keep the full connected story in view. You end up with fragments and a lot of manual work to prove that the same pattern is repeating across linked entities.

Graph analysis helps in general because it treats relationships as data and lets teams trace the connection paths that explain how activities link together. TigerGraph fits when teams need connection analysis to be native and repeatable as the investigation expands, when the output needs to remain reviewable at investigation depth, and when that analysis must execute quickly across large, evolving datasets.

TigerGraph can support coordinated timing reviews by running graph queries that expand from an alert to related entities and return the connecting paths used in the analysis as part of the output. 

That means reviewers can see what was repeated, which entities were linked, and which connection path was used to justify treating separate events as one connected pattern. The exact thresholds, windows, and escalation criteria remain program-defined.

Next Steps for Teams That Want to Operationalize Coordinated Timing

Start with what your reviewers will accept as evidence, then work backward.

  1. Define the pattern in terms of a risk scenario. Document the time window and the types of connections that make alignment meaningful in your environment.
  2. Require a connected explanation in escalations. Case notes should show the linked entities and the repeat timing pattern, not only an alert label.
  3. Standardize the review view. Analysts should see the same connected timing picture across queues and teams, so escalation decisions do not drift case by case.

If the timing narrative depends on screenshots, spreadsheets or investigator memory, it will not scale. A practical next step is to run a quick test on recent coordination-related reviews and confirm whether your current workflow can return a consistent, reviewable explanation of what repeated and how the entities were connected. 

If not, we would love to hear from you. TigerGraph can produce the path evidence your reviewers need without manual reconstruction.

Frequently Asked Questions

1. What Are Coordinated Timing Patterns in Financial Crime And AML Detection?

 Coordinated timing patterns are repeated sequences of activity across connected entities within the same time window. Not one account. A network. For example: Funds move through multiple accounts that share a device or identity signal, hitting the same intermediary in the same order within hours. Each transaction looks ordinary. The sequence repeating across the network is not. Traditional AML detection sees transactions. Coordinated fraud shows up in multi-hop patterns over time. The signal isn’t the transaction. It’s the pattern repeating across relationships.

2. Why do Traditional AML and Fraud Detection Systems Miss Coordinated Behavior?

Because they’re built to detect events, while fraud operates as a network. Most fraud detection software evaluates: one account, one transaction, and one threshold. But coordinated fraud is structured to avoid exactly that: activity is split across entities, signals stay individually weak, and nothing crosses a threshold. For example: A fraud ring distributes activity across 20 accounts, reusing the same routing path within a narrow time window. No single account triggers an alert. The pattern only exists across multi-hop connections and timing.

The result: missed fraud rings, high false positives, and manual reconstruction during investigations. This isn’t a model problem. It’s a structural one. Fraud is not a series of events. It’s a system of relationships.

3. How does Graph Analytics Improve Fraud Detection and AML Monitoring?

 Graph analytics treats relationships as first-class data—and makes coordinated behavior visible. Instead of evaluating isolated events, it evaluates: how entities are connected, how activity repeats across those connections, and how behavior moves through the network over time. For example: Transactions repeatedly pass through the same intermediary across different accounts, following the same path within a defined window. Graph analysis surfaces both the repetition and the shared route. This enables: detection of coordinated activity across connected entities, identification of repeated sequences and routing patterns, and traversal of multi-hop relationships at investigation depth. And critically: it returns to the path. Not a score. Not a guess. The actual connections and timing that explain the alert. If AI predicts risk, graph proves it.

 4. What Makes an AML or Fraud Alert Explainable and Regulator-Ready?

An alert is explainable when it shows how the decision was made one step at a time. A regulator-ready alert includes: the entities involved, the relationships between them, the time window of activity, the repeated pattern, and the multi-hop connection path. For example: An alert that shows multiple accounts sharing an identity signal, executing the same sequence, and routing through a common intermediary with the exact paths connecting them. Anything less is a black box. If the path isn’t visible, the decision isn’t defensible. In AML and compliance, that leads to: audit exposure, slower investigations, and inconsistent outcomes. Explainability isn’t a feature. It’s a requirement.

5. How do Financial Institutions Detect Coordinated Fraud in Real Time?

By shifting from event-based monitoring to connected, real-time analysis.

That requires four capabilities: 1. Unify entities: Accounts, identities, devices, and counterparties must be connected, 2 Model relationships directly: Connections are stored and queryable—not reconstructed later. 3. Apply consistent time windows: To detect synchronized and repeated behavior, and 4. Return paths with every alert: So investigators see the full connected pattern. For example: As transactions occur, the system expands across connected entities, detects repeated sequences within a defined window, and returns the path linking the activity. Fraud forms across a network. Detection must operate on the network in real time. Without that, detection becomes reconstruction.

 

About the Author

Learn More About PartnerGraph

TigerGraph Partners with organizations that offer
complementary technology solutions and services.
Dr. Jay Yu

Dr. Jay Yu | VP of Product and Innovation

Dr. Jay Yu is the VP of Product and Innovation at TigerGraph, responsible for driving product strategy and roadmap, as well as fostering innovation in graph database engine and graph solutions. He is a proven hands-on full-stack innovator, strategic thinker, leader, and evangelist for new technology and product, with 25+ years of industry experience ranging from highly scalable distributed database engine company (Teradata), B2B e-commerce services startup, to consumer-facing financial applications company (Intuit). He received his PhD from the University of Wisconsin - Madison, where he specialized in large scale parallel database systems

Smiling man with short dark hair wearing a black collared shirt against a light gray background.

Todd Blaschka | COO

Todd Blaschka is a veteran in the enterprise software industry. He is passionate about creating entirely new segments in data, analytics and AI, with the distinction of establishing graph analytics as a Gartner Top 10 Data & Analytics trend two years in a row. By fervently focusing on critical industry and customer challenges, the companies under Todd's leadership have delivered significant quantifiable results to the largest brands in the world through channel and solution sales approach. Prior to TigerGraph, Todd led go to market and customer experience functions at Clustrix (acquired by MariaDB), Dataguise and IBM.