Event Sequencing
Definition: a chain of states or events that matters only together, not individually, within one model or across linked models. It enforces a one after another approach.
Construction: within a model, a Dictionary (KVP) holds the last state and is compared to the current Payload.
Across models, a TTL Counter is incremented in one model and read in a linked model through a common key, which is
possible because a TTL Counter can be incremented across models. Lifecycle chains, channel hopping and takeover chains
are domain dressing on this one mechanism, and are not separate classes. See the Rule Taxonomy.
Event Sequencing: Priority Enforces One After Another
Event Sequencing reuses the TTL Counter mechanism of Velocity and Volume, and priority is decisive. Counters are updated inside the invocation as each incrementing Activation Rule matches, and Activation Rules are evaluated in ascending Priority order (a lower number is evaluated first). For a genuine one-after sequence the rule that tests the chain must be evaluated before the rule that increments the step counter for the current event, so it has a high order (evaluated early) Priority. Otherwise the current event counts as its own predecessor and the sequence is satisfied by a single event.
Event Sequencing: Cross-Model Example
Alert when a customer has more than three failed logins, then adds a new beneficiary, then makes a financial transaction
over a certain amount. Each step is a different model, joined by a common key such as CustomerId, and each step is
armed only when the step before it has happened.
| Step | Model | Rule that increments the counter | Counter incremented (defined in the model that reads it) |
|---|---|---|---|
| 1 | Login model | Failed login: Matched = Payload.LoginResult.MatchEqual("Failed") |
FailedLogins in the beneficiary model |
| 2 | Beneficiary model | New beneficiary, gated on step 1: Matched = TTLCounter.FailedLogins.RequireGreater(3).Against(Payload.IsNewBeneficiary).MatchIsTrue() |
BeneficiaryAfterFailedLogins in the transaction model |
| 3 | Transaction model | Alert, gated on step 2: Matched = TTLCounter.BeneficiaryAfterFailedLogins.RequireGreater(0).Against(Payload.CurrencyAmount).MatchGreater(5000) |
None. This is the alerting Activation Rule. |
The gate in each step is what makes it a sequence rather than three independent counts: the step 2 counter cannot
increment unless the step 1 counter had already crossed its threshold, and the step 3 alert cannot fire unless step 2
had incremented. The TTL Counter interval on each counter bounds how long the chain may take, for example Hours /
24.
Event Sequencing: Construction Steps
Define a TTL Counter per link in the chain, in the model that will read it, keyed on the common entity. Increment each counter from an Activation Rule in the model where that event occurs, choosing the target model in the Increment TTL Counter options (see TTL Counter Activation Rule Incrementation). Gate each incrementing rule on the previous link’s counter. Set Priority so that gates are evaluated before their own increment. Threshold the last counter in the alerting rule. The common key must be present in the payload of every model in the chain, otherwise the increment is skipped for that event.
Event Sequencing: Within-Model Example
Within one model, a Dictionary KVP holding the last state for the entity is compared with the current payload, for
example alerting when a status moves from Dormant directly to a high value withdrawal:
Matched = Dictionary.LastAccountStatus.RequireIsZero().Against(Payload.CurrencyAmount).MatchGreater(5000)
A Dictionary is populated during model synchronisation from the user interface, a CSV upload, the database or the API. It is not written by the invocation itself, so it holds state that something external maintains. Where the events themselves must maintain the state, use the cross-model TTL Counter mechanism above. The value of a Dictionary lookup is a number, and is zero when the key is absent from the payload or the Dictionary, so choose encodings where zero is the safe default. See Dictionary.
Event Sequencing: Common Faults
Symptoms of a misbuilt Event Sequencing rule, with the likely cause.
| Symptom in an Event Sequencing rule | Likely cause |
|---|---|
| The alert fires on a single event | The gate is evaluated after its own increment, so the event satisfies its own predecessor. Lower the gate’s Priority number. |
| The alert never fires | The common key is missing from a model’s payload, so the increment is skipped; or the window is shorter than the chain. |
| Steps fire in the wrong order | The increment for a later step is not gated on the earlier step’s counter. |
| Chain fires for unrelated customers | The TTL Counter Data Name is not the shared entity key. |
Examples by Sub-Class
Validated. Every fragment in this section is compiled individually through the Jube Parser, with its payload fields and its TTL Counter, Abstraction, Calculation, List and Sanction tokens declared, so each extension method and argument type is checked against the engine. Compilation does not validate a rule’s logic or its thresholds, which are illustrative placeholders to be tuned on data.
5.1 Account takeover chains
| # | Example | Description | Jube construction | Fragment | Notes |
|---|---|---|---|---|---|
| 5.1-01 | Password reset followed by payment | Credential reset then payment within a short window. | TTL Counter PasswordResetLastHour (Data Name AccountId, Interval Hours / 1, Sum off) is incremented by the activation rule that matches the password-reset event, and the payment rule reads it. Reset events must reach the model that defines the counter, because the engine increments only on payloads that carry the key. Payload.EventType is a placeholder field name. |
Matched = TTLCounter.PasswordResetLastHour.RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 1h |
| 5.1-02 | Credential change followed by new payee and payment | Change, add beneficiary, pay. | TTL Counters CredentialChangeLast24Hours and PayeeAddedLast24Hours (Data Name AccountId, Interval Hours / 24, Sum off) are incremented by the credential-change and payee-add rules. The payment rule reads both. Order between the two prior steps is not enforced, only co-occurrence in the window. |
Matched = TTLCounter.CredentialChangeLast24Hours.RequireGreater(0).Against(TTLCounter.PayeeAddedLast24Hours).RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 24h |
| 5.1-03 | Phone number change followed by OTP request and payment | Contact change then authentication then outflow. | TTL Counters PhoneChangeLast24Hours and OtpRequestLast24Hours (Data Name AccountId, Interval Hours / 24, Sum off) are incremented by the phone-change and OTP-request rules, and the payment rule reads both. The OTP request must be an event the bank feeds to Jube, and the order between the two prior steps is co-occurrence only. |
Matched = TTLCounter.PhoneChangeLast24Hours.RequireGreater(0).Against(TTLCounter.OtpRequestLast24Hours).RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 24h |
| 5.1-04 | Email change followed by password reset | Email replaced and then recovery initiated. | TTL Counter EmailChangeLastHour (Data Name AccountId, Interval Hours / 1, Sum off) is incremented by the email-change rule. The password-reset-request rule reads it, so the prior email change is checked in order because the recovery request is the current event. |
Matched = TTLCounter.EmailChangeLastHour.RequireGreater(0).Against(Payload.EventType).MatchEqual("PasswordResetRequest") |
Tag: Sequence · Fraud · Account · 1h |
| 5.1-06 | New device enrolment followed by payment | First-seen device registers then pays. | TTL Counter DeviceEnrolledLast24Hours (Data Name AccountId, Interval Hours / 24, Sum off) is incremented by the device-enrolment rule, and the payment rule reads it. First-seen device is approximated by the enrolment event inside the window, so there is no device history beyond 24 hours. |
Matched = TTLCounter.DeviceEnrolledLast24Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 24h |
| 5.1-07 | New device enrolment followed by limit increase | Device added then limits raised. | The same TTL Counter DeviceEnrolledLast24Hours as 5.1-06 (Data Name AccountId, Interval Hours / 24) is read by the limit-increase rule. The limit increase is the current event and the enrolment is the prior counted event. |
Matched = TTLCounter.DeviceEnrolledLast24Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("LimitIncrease") |
Tag: Sequence · Fraud · Account · 24h |
| 5.1-08 | Failed logins followed by successful login and payment | Brute-force success chain. | TTL Counters FailedLoginLastHour and LoginSuccessLastHour (Data Name AccountId, Interval Hours / 1, Sum off) are incremented by the failed-login and successful-login rules, and the payment rule reads both. The threshold of 5 is a placeholder for the policy value N, and the failure-then-success order is only co-occurrence within the hour. |
Matched = TTLCounter.FailedLoginLastHour.RequireGreaterOrEqual(5).Against(TTLCounter.LoginSuccessLastHour).RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 1h |
| 5.1-09 | Login from new country followed by payee addition | Foreign login then payee added. | TTL Counter ForeignLoginLastHour (Data Name AccountId, Interval Hours / 1, Sum off) is incremented by a login rule whose own condition is that the login country differs from the KYC residence country, so only foreign logins count. The payee-addition rule reads it. The approximation of new country by residence mismatch needs that increment condition to be checked before reliance. |
Matched = TTLCounter.ForeignLoginLastHour.RequireGreater(0).Against(Payload.EventType).MatchEqual("PayeeAdd") |
Tag: Sequence · Fraud · Account · 1h |
| 5.1-10 | Dormant account login followed by contact change and transfer | Wake-up takeover pattern. | TTL Counter Activity12Months (Data Name AccountId, Interval Months / 12, code m, Sum off) is incremented by every account event. The login rule reads it with MatchIsZero() and must have the lower Priority number so the read happens before its own increment. A TTL Counter DormantLoginLast7Days (Data Name AccountId, Interval Days / 7) is incremented on that dormant login, and the transfer rule reads it together with ContactChangeLast7Days. |
Matched = TTLCounter.DormantLoginLast7Days.RequireGreater(0).Against(TTLCounter.ContactChangeLast7Days).RequireGreater(0).Against(Payload.EventType).MatchEqual("Transfer") |
Check: 12-month dormancy is a policy choice; statutory dormancy rules for unclaimed funds differ by jurisdiction. Tag: Sequence · Fraud · Account · 7d |
| 5.1-11 | Security question change followed by payment | Authentication details changed then pay. | TTL Counter AuthDetailChangeLast24Hours (Data Name AccountId, Interval Hours / 24, Sum off) is incremented by the security-question change rule, and the payment rule reads it. The change is a feed event, so no comparison is needed. |
Matched = TTLCounter.AuthDetailChangeLast24Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 24h |
| 5.1-12 | MFA disabled followed by payment | Protection removed then outflow. | TTL Counter MfaDisabledLast24Hours (Data Name AccountId, Interval Hours / 24, Sum off) is incremented by the MFA-disabled event rule, and the payment rule reads it. The MFA-disabled event must be fed to Jube. |
Matched = TTLCounter.MfaDisabledLast24Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 24h |
| 5.1-13 | Alert/notification settings disabled followed by payment | Notifications switched off then payment. | TTL Counter AlertsDisabledLast24Hours (Data Name AccountId, Interval Hours / 24, Sum off) is incremented by the notification-settings change rule, and the payment rule reads it. The notification-setting change must be fed to Jube. |
Matched = TTLCounter.AlertsDisabledLast24Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 24h |
| 5.1-14 | Card replaced to new address followed by use | Card reissue to new address then activation and spend. | TTL Counters CardAddressChangeLast14Days and CardActivationLast14Days (Data Name CardId, Interval Days / 14, Sum off) are incremented by the address-change and activation rules, and the card-spend rule reads both. Reissue to a new address and activation are two prior counted steps, so their order is co-occurrence only. |
Matched = TTLCounter.CardAddressChangeLast14Days.RequireGreater(0).Against(TTLCounter.CardActivationLast14Days).RequireGreater(0).Against(Payload.EventType).MatchEqual("CardSpend") |
Tag: Sequence · Fraud · Card · 14d |
| 5.1-15 | Card activated then immediate ATM cash-out | Activation and withdrawal in succession. | TTL Counter CardActivationLast2Hours (Data Name CardId, Interval Hours / 2, Sum off) is incremented by the card-activation rule, and the ATM-withdrawal rule reads it. The card key must be the card identifier on both the activation and the ATM events. |
Matched = TTLCounter.CardActivationLast2Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("ATMWithdrawal") |
Tag: Sequence · Fraud · Card · 2h |
| 5.1-16 | Wallet provisioning followed by high-value spend | Token provisioned then spend. | TTL Counter WalletProvisionLast24Hours (Data Name CardId, Interval Hours / 24, Sum off) is incremented by the wallet-provisioning rule, and the spend rule reads it with a high-value test on CurrencyAmount. The threshold of 9000 is a placeholder for the policy value. |
Matched = TTLCounter.WalletProvisionLast24Hours.RequireGreater(0).Against(Payload.CurrencyAmount).MatchGreater(9000) |
Tag: Sequence · Fraud · Card · 24h |
| 5.1-17 | Remote-access session followed by payment | RAT-flagged session then payment. | Single event. The remote-access verdict is a device-intelligence vendor result, supplied upstream as the RemoteAccessDetectedFlag payload flag (placeholder). The sequence with the later payment is two rules, outside this fragment. | Matched = Payload.RemoteAccessDetectedFlag.MatchIsTrue() |
Tag: Sequence · Fraud · Account · 1h |
| 5.1-18 | Login via link followed by payment (phishing) | Session started from suspicious referral then payment. | A List SuspiciousReferrers holds referrer hosts that analysts maintain. The login rule increments TTL Counter SuspiciousLoginLastHour (Data Name AccountId, Interval Hours / 1, Sum off) only when its own condition, Payload.ReferrerHost.MatchNormalisedInList(List.SuspiciousReferrers), matches, and the payment rule reads the counter. The list is reference data, so its currency is the limit, and the counter’s increment is the conditional part. |
Matched = TTLCounter.SuspiciousLoginLastHour.RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 1h |
5.2 Authorised push payment scam chains
| # | Example | Description | Jube construction | Fragment | Notes |
|---|---|---|---|---|---|
| 5.2-01 | Large credit followed by immediate outbound to new payee | Funds arrive then are paid out to a new beneficiary. | TTL Counter CreditSumLast24Hours (Data Name AccountId, Interval Hours / 24, Sum on with Data Value CurrencyAmount) is incremented by the credit rule. TTL Counter PayeeSeenLast365Days (Data Name PayeeId, Interval Days / 365, Sum off) is incremented by the payment rule, and its increment rule must have the lower Priority number so the count includes the current payment, making a value of 1 or less a first payment to that payee. PayeeId is a placeholder key. The threshold of 10000 is a placeholder. |
Matched = TTLCounter.CreditSumLast24Hours.RequireGreater(10000).Against(TTLCounter.PayeeSeenLast365Days).RequireLessOrEqual(1).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 24h |
| 5.2-02 | Savings withdrawal followed by outbound payment | Funds moved from savings to current then sent. | TTL Counter SavingsWithdrawalLast24Hours (Data Name AccountId, Interval Hours / 24, Sum off) is incremented by the savings-to-current movement event, and the outbound payment rule reads it. The movement must be a fed event. |
Matched = TTLCounter.SavingsWithdrawalLast24Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 24h |
| 5.2-03 | Investment/loan drawdown followed by transfer to crypto | Borrowing then crypto purchase. | TTL Counter LoanDrawdownLast7Days (Data Name AccountId, Interval Days / 7, Sum off) is incremented by the loan-drawdown rule. The payment rule reads it and tests the payee name against the maintained List CryptoExchanges, so identification depends on that list being kept current. PayeeName is a placeholder field. |
Matched = TTLCounter.LoanDrawdownLast7Days.RequireGreater(0).Against(Payload.PayeeName).RequireNormalisedInList(List.CryptoExchanges).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 7d |
| 5.2-04 | Repeated escalating payments to same new payee | Rising amounts to one payee in days. | Abstraction Rule PayeeMaxAmountLast7Days (Search Key PayeeId, Search Interval Days / 7, Function Max over CurrencyAmount) holds the largest prior payment to that payee. TTL Counter PayeePaymentsLast7Days (Data Name PayeeId, Interval Days / 7, Sum off) is incremented by the payment rule. This tests a new high against the prior maximum, a proxy for escalation, and the abstraction window must exclude the current payload or the comparison can never be true. |
Matched = Payload.CurrencyAmount.RequireGreater(Abstraction.PayeeMaxAmountLast7Days).Against(TTLCounter.PayeePaymentsLast7Days).RequireGreaterOrEqual(3).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 7d |
| 5.2-05 | Payment after long call session (vishing) | Call-signal plus payment. | TTL Counter LongCallLastHour (Data Name CustomerId, Interval Hours / 1, Sum off) is incremented by a call-event rule whose own condition is that the call duration is over the threshold. The payment rule reads it. Call events must be fed to Jube. |
Matched = TTLCounter.LongCallLastHour.RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 1h |
| 5.2-06 | Payment immediately after warning acknowledged | Customer overrides scam warning then pays. | TTL Counter WarningAcknowledgedLast5Minutes (Data Name CustomerId, Interval Minutes / 5, interval code n, Sum off) is incremented by the warning-acknowledged rule, and the payment rule reads it. Minutes are written as n, because m is months in Jube. |
Matched = TTLCounter.WarningAcknowledgedLast5Minutes.RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Check: Interval written as 5m in the source means 5 minutes; Jube reads m as months. Tag: Sequence · Fraud · Account · 5m |
| 5.2-07 | First payment to crypto after account inactivity | Dormancy then crypto purchase. | TTL Counter AccountActivityLast30Days (Data Name AccountId, Interval Days / 30, Sum off) is incremented by every account event, and the crypto-payment rule reads it with MatchIsZero(). Its Priority number must be lower than the incrementing rule so the read happens before this payment is counted. PayeeName is a placeholder field. |
Matched = TTLCounter.AccountActivityLast30Days.RequireIsZero().Against(Payload.PayeeName).RequireNormalisedInList(List.CryptoExchanges).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 30d |
| 5.2-08 | Multiple failed payments then success to a different payee | Tries blocked, then retries elsewhere. | TTL Counter FailedPaymentLast2Hours (Data Name AccountId, Interval Hours / 2, Sum off) is incremented by the failed-payment rule. Abstraction Rule DistinctPayeesLast2Hours (Search Key AccountId, Search Interval Hours / 2, Function Distinct Count over PayeeId) counts payees tried. The distinct count includes the failed attempts, so it measures payees tried, not only the successful one. The threshold of 3 is a placeholder for N. |
Matched = TTLCounter.FailedPaymentLast2Hours.RequireGreaterOrEqual(3).Against(Abstraction.DistinctPayeesLast2Hours).RequireGreater(1).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 2h |
| 5.2-09 | Romance/investment scam pattern | Increasing sequence of transfers to different new payees from an older customer. | Abstraction Rule DistinctPayeesLast60Days (Search Key AccountId, Search Interval Days / 60, Function Distinct Count over PayeeId) counts new payees. TTL Counter PaymentSumLast60Days (Data Name AccountId, Interval Days / 60, Sum on with Data Value CurrencyAmount) holds value moved. The age test reads Payload.AgeInYears, a placeholder field derived upstream from date of birth. This is a proxy: the increasing pattern is not tested, and distinct new payees and value stand in for it. The age and value numbers are placeholders. |
Matched = Abstraction.DistinctPayeesLast60Days.RequireGreaterOrEqual(3).Against(TTLCounter.PaymentSumLast60Days).RequireGreater(50000).Against(Payload.AgeInYears).MatchGreaterOrEqual(70) |
Check: Age threshold for vulnerable customers is a policy or regulatory choice; verify before use. Tag: Sequence · Fraud · Account · 60d |
5.3 Money-laundering lifecycle chains
| # | Example | Description | Jube construction | Fragment | Notes |
|---|---|---|---|---|---|
| 5.3-01 | Placement then layering within hours | Cash deposit followed by quick transfers out. | TTL Counter CashDepositSumLast48Hours (Data Name AccountId, Interval Hours / 48, Sum on with Data Value CurrencyAmount) is incremented by the cash-deposit rule. TTL Counter OutboundTransferLast48Hours (Data Name AccountId, Interval Hours / 48, Sum off) is incremented by the outbound-transfer rule, and the transfer rule reads both. Layering is a count of outbound transfers in the 48-hour window of this row, not a count in hours. |
Matched = TTLCounter.CashDepositSumLast48Hours.RequireGreater(9000).Against(TTLCounter.OutboundTransferLast48Hours).RequireGreaterOrEqual(3).Against(Payload.EventType).MatchEqual("Transfer") |
Tag: Sequence · AML · Account · 48h |
| 5.3-02 | Cash deposit followed by international wire | Deposit then cross-border payment. | TTL Counter CashDepositLast72Hours (Data Name AccountId, Interval Hours / 72, Sum off) is incremented by the cash-deposit rule, and the international-wire rule reads it. The cross-border flag comes from the wire payload. |
Matched = TTLCounter.CashDepositLast72Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("InternationalWire") |
Tag: Sequence · AML · Account · 72h |
| 5.3-03 | Cash deposit followed by crypto purchase | Deposit then virtual asset purchase. | TTL Counter CashDepositLast72Hours (Data Name AccountId, Interval Hours / 72, Sum off) is incremented by the cash-deposit rule. The payment rule reads it and tests the payee name against the maintained List CryptoExchanges, so a virtual asset purchase is identified by that list. PayeeName is a placeholder field. |
Matched = TTLCounter.CashDepositLast72Hours.RequireGreater(0).Against(Payload.PayeeName).MatchNormalisedInList(List.CryptoExchanges) |
Tag: Sequence · AML · Account · 72h |
| 5.3-04 | Inbound wire followed by immediate outbound wire to different jurisdiction | Rapid pass-through across borders. | TTL Counter InboundWireLast24Hours (Data Name AccountId, Interval Hours / 24, Sum off) is incremented by the inbound-wire rule, and the outbound-wire rule reads it. The jurisdiction test compares the beneficiary country with the residence country, not with the inbound leg, because comparing with the inbound leg would need prior state. BeneficiaryCountry and ResidenceCountry are placeholder fields. |
Matched = TTLCounter.InboundWireLast24Hours.RequireGreater(0).Against(Payload.EventType).RequireEqual("OutboundWire").MatchWhen(Payload.BeneficiaryCountry.CountryAlpha2() <> Payload.ResidenceCountry.CountryAlpha2()) |
Tag: Sequence · AML · Account · 24h |
| 5.3-05 | Credit followed by cash withdrawal of similar amount | Money in and cash out matching. | TTL Counter CreditSumLast24Hours (Data Name AccountId, Interval Hours / 24, Sum on with Data Value CurrencyAmount) is incremented by the credit rule. The cash-withdrawal rule reads it and tests that the withdrawal is within 10 percent of the credited total. The tolerance of 10 is a policy value. |
Matched = TTLCounter.CreditSumLast24Hours.RequireGreater(0).Against(Payload.CurrencyAmount).RequireWithinPercentOf(TTLCounter.CreditSumLast24Hours, 10).Against(Payload.EventType).MatchEqual("CashWithdrawal") |
Tag: Sequence · AML · Account · 24h |
| 5.3-06 | Loan drawdown followed by third-party transfer | Loan proceeds sent on. | TTL Counter LoanDrawdownLast7Days (Data Name AccountId, Interval Days / 7, Sum off) is incremented by the loan-drawdown rule. The third party is approximated by low name similarity between the payee and the account holder, using the SimilarityTo string extension. The threshold of 0.5 is a policy value. |
Matched = TTLCounter.LoanDrawdownLast7Days.RequireGreater(0).MatchWhen(Payload.PayeeName.SimilarityTo(Payload.AccountHolderName) < 0.5) |
Tag: Sequence · AML · Account · 7d |
| 5.3-07 | Gift card purchase followed by redemption/cash-out | Convert value to cash equivalents then exit. | TTL Counter GiftCardPurchaseSumLast7Days (Data Name CustomerId, Interval Days / 7, Sum on with Data Value CurrencyAmount) is incremented by the gift-card purchase rule, and the redemption rule reads it. The gift-card category must be a fed merchant or product category. |
Matched = TTLCounter.GiftCardPurchaseSumLast7Days.RequireGreater(0).Against(Payload.EventType).MatchEqual("GiftCardRedemption") |
Tag: Sequence · AML · Customer · 7d |
| 5.3-08 | Prepaid load followed by ATM withdrawal | Load then cash. | TTL Counter PrepaidLoadLast24Hours (Data Name CardId, Interval Hours / 24, Sum off) is incremented by the prepaid-load rule, and the ATM-withdrawal rule reads it. The prepaid load must be fed with the card key. |
Matched = TTLCounter.PrepaidLoadLast24Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("ATMWithdrawal") |
Tag: Sequence · AML · Card · 24h |
| 5.3-09 | Securities purchase followed by early sale and transfer | Buy, sell, withdraw. | TTL Counters SecuritiesBuyLast7Days and SecuritiesSellLast7Days (Data Name AccountId, Interval Days / 7, Sum off) are incremented by the buy and sell rules, and the withdrawal rule reads both. The buy and sell are two prior counted steps, so their order is co-occurrence only. |
Matched = TTLCounter.SecuritiesBuyLast7Days.RequireGreater(0).Against(TTLCounter.SecuritiesSellLast7Days).RequireGreater(0).Against(Payload.EventType).MatchEqual("Withdrawal") |
Tag: Sequence · AML · Account · 7d |
| 5.3-10 | Insurance purchase followed by early surrender | Policy then rapid cancellation. | TTL Counter PolicyPurchaseLast90Days (Data Name CustomerId, Interval Days / 90, Sum off) is incremented by the policy-purchase rule, and the surrender rule reads it. The 90-day window is what defines early in this row. |
Matched = TTLCounter.PolicyPurchaseLast90Days.RequireGreater(0).Against(Payload.EventType).MatchEqual("PolicySurrender") |
Check: Early-surrender and cooling-off periods vary by product and jurisdiction; verify the window. Tag: Sequence · AML · Policy · 90d |
| 5.3-12 | Trade finance cycle: LC issue, amend, cancel, refund | Repeated instruments with money returning in different form. | TTL Counters LcIssueLast90Days and LcCancelLast90Days (Data Name CustomerId, Interval Days / 90, Sum off) are incremented by the letter-of-credit issue and cancel rules, and the refund rule reads both. Trade-finance events must be fed to Jube, and the order of the prior steps is co-occurrence only. |
Matched = TTLCounter.LcIssueLast90Days.RequireGreater(0).Against(TTLCounter.LcCancelLast90Days).RequireGreater(0).Against(Payload.EventType).MatchEqual("LcRefund") |
Tag: Sequence · AML · Customer · 90d |
| 5.3-13 | Account opened, funded, emptied, closed | Full short lifecycle. | TTL Counters AccountOpenLast60Days (count) and AccountFundingSumLast60Days (Sum on with Data Value CurrencyAmount), both with Data Name AccountId and Interval Days / 60, are incremented by the open and funding rules. The close rule reads both, and tests that the closing balance is below 1 at close, so the emptied state is read from the closing balance. The funding threshold of 5000 is a policy value. |
Matched = TTLCounter.AccountOpenLast60Days.RequireGreater(0).Against(TTLCounter.AccountFundingSumLast60Days).RequireGreater(5000).Against(Payload.EventType).RequireEqual("AccountClose").Against(Payload.ClosingBalance).MatchLess(1) |
Tag: Sequence · AML · Account · 60d |
| 5.3-14 | Round-trip funds: out then back from different source | Funds return via a different party. | TTL Counter OutflowSumLast30Days (Data Name AccountId, Interval Days / 30, Sum on with Data Value CurrencyAmount) is incremented by the outflow rule. The inbound rule reads it and tests that the inbound amount is within 5 percent of the outflow total. This is a proxy: the different source is not tested, because the earlier payee is not keyed. The tolerance of 5 is a policy value. |
Matched = TTLCounter.OutflowSumLast30Days.RequireGreater(0).Against(Payload.CurrencyAmount).RequireWithinPercentOf(TTLCounter.OutflowSumLast30Days, 5).Against(Payload.EventType).MatchEqual("Inbound") |
Tag: Sequence · AML · Account · 30d |
| 5.3-15 | Smurf deposits followed by consolidation | Multiple small deposits then single large transfer. | Abstraction Rule DepositMaxLast7Days (Search Key AccountId, Search Interval Days / 7, Function Max over CurrencyAmount) holds the largest deposit. TTL Counters DepositCountLast7Days (count) and DepositSumLast7Days (Sum on) are both Data Name AccountId, Interval Days / 7, and are incremented by the deposit rule. The pipeline form of IsJustBelowThreshold tests that the largest deposit sits just under the reporting threshold, which implies every deposit is below it. The threshold and margin are placeholders. |
Matched = Abstraction.DepositMaxLast7Days.RequireIsJustBelowThreshold(10000, 10).Against(TTLCounter.DepositCountLast7Days).RequireGreaterOrEqual(3).Against(TTLCounter.DepositSumLast7Days).MatchGreater(10000) |
Check: Cash reporting thresholds differ by jurisdiction (for example USD 10,000 for US currency transaction reports); verify the threshold and margin for the bank’s jurisdiction. Tag: Sequence · AML · Account · 7d |
| 5.3-16 | Remittance receipt followed by cash pick-up and re-send | Chain through MSB. | TTL Counters RemittanceInLast7Days and CashPickupLast7Days (Data Name CustomerId, Interval Days / 7, Sum off) are incremented by the remittance-receipt and cash-pickup rules, and the re-send rule reads both. Only the bank’s own legs are visible to Jube, so the money-service-business leg outside the bank is not. |
Matched = TTLCounter.RemittanceInLast7Days.RequireGreater(0).Against(TTLCounter.CashPickupLast7Days).RequireGreater(0).Against(Payload.EventType).MatchEqual("RemittanceSend") |
Check: Money-service-business obligations and the scope of reporting vary by jurisdiction; verify. Tag: Sequence · AML · Customer · 7d |
| 5.3-17 | Casino chips bought, minimal play, cashed out | Chip purchase then redemption via cheque. | TTL Counters ChipPurchaseSumLast24Hours and WagerSumLast24Hours (Data Name PlayerId, Interval Hours / 24, Sum on with Data Value CurrencyAmount) are incremented by the chip-purchase and wager rules. The cheque cash-out rule reads the chip total and tests that wagers are under 10 percent of it, using the PercentOf calculation. Wager totals come from the gaming platform feed, and 10 percent is a policy value. |
Matched = TTLCounter.ChipPurchaseSumLast24Hours.RequireGreater(0).Against(TTLCounter.WagerSumLast24Hours.PercentOf(TTLCounter.ChipPurchaseSumLast24Hours)).RequireLess(10).Against(Payload.EventType).MatchEqual("ChequeCashOut") |
Tag: Sequence · AML · Player · 24h |
| 5.3-18 | Virtual asset deposit followed by mixer/privacy tool withdrawal | Deposit then outflow to obfuscation service. | A List MixerAddresses holds destination addresses from the chain-analytics feed. TTL Counter VirtualAssetDepositLast24Hours (Data Name CustomerId, Interval Hours / 24, Sum off) is incremented by the virtual-asset deposit rule. The outflow rule uses MatchInList, an exact match, because addresses are case sensitive. DestinationAddress is a placeholder field. |
Matched = TTLCounter.VirtualAssetDepositLast24Hours.RequireGreater(0).Against(Payload.DestinationAddress).MatchInList(List.MixerAddresses) |
Tag: Sequence · AML · Customer · 24h |
| 5.3-19 | Chain-hopping: asset swap across chains | Rapid swaps across tokens and chains. | Abstraction Rule DistinctChainsLast24Hours (Search Key CustomerId, Search Interval Hours / 24, Function Distinct Count over ChainId) counts chains used. TTL Counter AssetSwapLast24Hours (Data Name CustomerId, Interval Hours / 24, Sum off) is incremented by the asset-swap rule. Swap events must be fed with the chain identifier. The threshold of 3 is a placeholder. |
Matched = Abstraction.DistinctChainsLast24Hours.RequireGreaterOrEqual(3).Against(TTLCounter.AssetSwapLast24Hours).MatchGreaterOrEqual(3) |
Tag: Sequence · AML · Customer · 24h |
5.4 Channel hopping and cross-channel sequences
| # | Example | Description | Jube construction | Fragment | Notes |
|---|---|---|---|---|---|
| 5.4-01 | Online activity followed by call-centre contact followed by payment | Social engineering sequence. | TTL Counters OnlineLoginLast24Hours and CallCentreContactLast24Hours (Data Name CustomerId, Interval Hours / 24, Sum off) are incremented by the online-login and call-centre rules, and the payment rule reads both. The channel order is co-occurrence only. |
Matched = TTLCounter.OnlineLoginLast24Hours.RequireGreater(0).Against(TTLCounter.CallCentreContactLast24Hours).RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 24h |
| 5.4-02 | Branch withdrawal following digital transfer failure | Hopping channels after block. | TTL Counter DigitalTransferFailedLast6Hours (Data Name AccountId, Interval Hours / 6, Sum off) is incremented by the failed digital-transfer event, and the branch cash-withdrawal rule reads it. The failure event must be fed with the account key. Channel is a placeholder field. |
Matched = TTLCounter.DigitalTransferFailedLast6Hours.RequireGreater(0).Against(Payload.Channel).RequireEqual("Branch").Against(Payload.EventType).MatchEqual("CashWithdrawal") |
Tag: Sequence · Fraud · Account · 6h |
| 5.4-03 | ATM withdrawal after online payment declined | Cash-out after e-channel decline. | TTL Counter OnlineDeclineLast6Hours (Data Name CardId, Interval Hours / 6, Sum off) is incremented by the online-decline rule, and the ATM-withdrawal rule reads it. Decline events must share the card key with ATM events. |
Matched = TTLCounter.OnlineDeclineLast6Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("ATMWithdrawal") |
Tag: Sequence · Fraud · Card · 6h |
| 5.4-04 | Card decline followed by wallet payment | Same spend retried through wallet. | TTL Counter CardDeclineLastHour (Data Name CardId, Interval Hours / 1, Sum off) is incremented by the card-decline rule, and the wallet-payment rule reads it. Wallet payments must carry the underlying card identifier so the key matches. |
Matched = TTLCounter.CardDeclineLastHour.RequireGreater(0).Against(Payload.Channel).MatchEqual("Wallet") |
Tag: Sequence · Fraud · Card · 1h |
| 5.4-05 | Online declined, then telephone banking approved | Channel change after decline. | TTL Counter OnlineDeclineAccountLast6Hours (Data Name AccountId, Interval Hours / 6, Sum off) is incremented by the online-decline rule keyed on the account, and the telephone-approval rule reads it. The channel change after the decline is co-occurrence only. |
Matched = TTLCounter.OnlineDeclineAccountLast6Hours.RequireGreater(0).Against(Payload.Channel).RequireEqual("Telephone").Against(Payload.EventType).MatchEqual("PaymentApproved") |
Tag: Sequence · Fraud · Account · 6h |
| 5.4-06 | Mobile login followed by web login from different country | Concurrent channels in different geographies. | TTL Counter MobileLoginLastHour (Data Name AccountId, Interval Hours / 1, Sum off) is incremented by the mobile-login rule. Abstraction Rule DistinctLoginCountriesLastHour (Search Key AccountId, Search Interval Hours / 1, Function Distinct Count over LoginCountry) counts login countries. This is an approximation: it tests more than one login country within the hour, not specifically mobile against web. |
Matched = TTLCounter.MobileLoginLastHour.RequireGreater(0).Against(Payload.Channel).RequireEqual("Web").Against(Abstraction.DistinctLoginCountriesLastHour).MatchGreater(1) |
Tag: Sequence · Fraud · Account · 1h |
| 5.4-07 | Balance enquiry then withdrawal at different ATM | Probing then cash-out. | TTL Counter BalanceEnquiryLastHour (Data Name CardId, Interval Hours / 1, Sum off) is incremented by the balance-enquiry rule. Abstraction Rule DistinctAtmsLastHour (Search Key CardId, Search Interval Hours / 1, Function Distinct Count over AtmId) counts the machines used. The withdrawal rule reads both. |
Matched = TTLCounter.BalanceEnquiryLastHour.RequireGreater(0).Against(Payload.EventType).RequireEqual("ATMWithdrawal").Against(Abstraction.DistinctAtmsLastHour).MatchGreater(1) |
Tag: Sequence · Fraud · Card · 1h |
| 5.4-08 | Customer support contact for limit increase then high-value transfer | Authority change then use. | TTL Counter LimitIncreaseSupportLast48Hours (Data Name CustomerId, Interval Hours / 48, Sum off) is incremented by the support-contact event for a limit increase, and the transfer rule reads it. The support-contact event must be fed to Jube. The threshold of 9000 is a policy value. |
Matched = TTLCounter.LimitIncreaseSupportLast48Hours.RequireGreater(0).Against(Payload.CurrencyAmount).RequireGreater(9000).Against(Payload.EventType).MatchEqual("Transfer") |
Tag: Sequence · Fraud · Account · 48h |
5.5 Card fraud and payment-flow sequences
| # | Example | Description | Jube construction | Fragment | Notes |
|---|---|---|---|---|---|
| 5.5-01 | Small test purchase followed by large purchase | Card test then cash-out. | Abstraction Rule CardMinimumLastHour (Search Key CardId, Search Interval Hours / 1, Function Min over CurrencyAmount) holds the smallest recent card payment, and the large-purchase rule compares the current amount with it. A small test purchase is a minimum below the test threshold within the hour. Both thresholds are placeholders. |
Matched = Payload.CurrencyAmount.RequireGreater(9000).Against(Abstraction.CardMinimumLastHour).MatchLess(50) |
Tag: Sequence · Fraud · Card · 1h |
| 5.5-02 | Multiple declines followed by approval at higher value | Probing for limits. | TTL Counter CardDeclineLastHour (Data Name CardId, Interval Hours / 1, Sum off) is incremented by the decline rule. Abstraction Rule DeclineMaxLastHour (Search Key CardId, Search Interval Hours / 1, Function Max over CurrencyAmount) has its own filter that selects declined events only, so its maximum is over declines. The approval rule reads the count and compares the approved amount with that maximum. |
Matched = TTLCounter.CardDeclineLastHour.RequireGreaterOrEqual(3).Against(Payload.EventType).RequireEqual("Approved").Against(Payload.CurrencyAmount).MatchGreater(Abstraction.DeclineMaxLastHour) |
Tag: Sequence · Fraud · Card · 1h |
| 5.5-03 | Auth then immediate reversal then re-auth to another merchant | Pre-authorisation abuse. | TTL Counter AuthReversalLastHour (Data Name CardId, Interval Hours / 1, Sum off) is incremented by the authorisation-reversal rule. Abstraction Rule DistinctMerchantsLastHour (Search Key CardId, Search Interval Hours / 1, Function Distinct Count over MerchantId) counts the merchants authorised, so re-authorisation to a second merchant is the distinct count. |
Matched = TTLCounter.AuthReversalLastHour.RequireGreater(0).Against(Abstraction.DistinctMerchantsLastHour).MatchGreater(1) |
Tag: Sequence · Fraud · Card · 1h |
| 5.5-04 | Refund without original purchase | Refund appears with no corresponding sale. | TTL Counter PurchaseSumLast90Days (Data Name CardId, Interval Days / 90, Sum on with Data Value CurrencyAmount) is incremented by the purchase rule. The refund rule reads it and tests that the refund exceeds all purchases on the card in the window. This is an approximation: merchant and date match are not tested. The 90-day window is a policy value. |
Matched = Payload.CurrencyAmount.RequireGreater(TTLCounter.PurchaseSumLast90Days).Against(Payload.EventType).MatchEqual("Refund") |
Tag: Sequence · Fraud · Merchant · single event |
| 5.5-05 | Refund to a different card than purchase | Mismatched card on refund. | Single event. The original purchase card is supplied upstream on the refund as OriginalCardId (placeholder). The refund is tested against it. | If (Payload.TxnType = "Refund" And Payload.CardId <> Payload.OriginalCardId) Then Return True |
Tag: Sequence · Fraud · Merchant · 7d |
| 5.5-06 | Purchase followed by chargeback followed by repeat purchase | Friendly fraud cycle. | TTL Counter ChargebackLast90Days (Data Name CardId, Interval Days / 90, Sum off) is incremented by the chargeback rule. TTL Counter DisputedMerchantLast90Days (Data Name CardMerchantKey, Interval Days / 90, Sum off) is incremented by the dispute rule. CardMerchantKey is a composite key built upstream, because Jube counters take a single key field, and is a placeholder. |
Matched = TTLCounter.ChargebackLast90Days.RequireGreater(0).Against(TTLCounter.DisputedMerchantLast90Days).RequireGreater(0).Against(Payload.EventType).MatchEqual("Purchase") |
Check: Chargeback time limits are set by card schemes; verify the 90d window against the scheme rules. Tag: Sequence · Fraud · Customer · 90d |
| 5.5-07 | Chip fallback to magnetic stripe | Fallback transactions after chip failure. | No counter is needed: this is a single-event test on the EMV fallback indicator, carried as the placeholder field EntryMode. |
Matched = Payload.EntryMode.MatchEqual("FallbackSwipe") |
Check: Fallback liability and chip-failure rules are set by card schemes; verify. Tag: Sequence · Fraud · Card · single event |
| 5.5-08 | Impossible card-present then card-not-present sequence | CP in one location then CNP elsewhere. | Implied travel speed from the previous card-present location to the current card-not-present location, using the implied-speed test on the current event. Upstream fields: Payload.CardNotPresentLatitude, Payload.CardNotPresentLongitude, Payload.CardPresentLatitude, Payload.CardPresentLongitude and Payload.CardPresentElapsedHours, supplied before Jube or by an inline-script hook. Speed 900 km/h and the one-hour window are illustrative placeholders. | Matched = Payload.CardNotPresentLatitude.MatchImpliedSpeedAbove(Payload.CardNotPresentLongitude, Payload.CardPresentLatitude, Payload.CardPresentLongitude, Payload.CardPresentElapsedHours, 900) |
Tag: Sequence · Fraud · Card · 1h |
| 5.5-09 | Merchant terminal key-in after multiple chip failures | Manual key-ins sequence. | TTL Counter ChipFailureLastHour (Data Name TerminalId, Interval Hours / 1, Sum off) is incremented by the chip-failure rule. The key-entry event reads it, and the terminal key is the terminal identifier. The threshold of 3 is a placeholder for N. |
Matched = TTLCounter.ChipFailureLastHour.RequireGreaterOrEqual(3).Against(Payload.EntryMode).MatchEqual("KeyEntered") |
Tag: Sequence · Fraud · Terminal · 1h |
| 5.5-10 | Cardholder dispute filed then further purchases at same merchant | Dispute inconsistency. | TTL Counter DisputeLast30Days (Data Name CardMerchantKey, Interval Days / 30, Sum off) is incremented by the dispute rule. CardMerchantKey is a composite key built upstream and is a placeholder. The purchase rule reads it. |
Matched = TTLCounter.DisputeLast30Days.RequireGreater(0).Against(Payload.EventType).MatchEqual("Purchase") |
Check: Dispute time limits are set by card schemes; verify the 30d window. Tag: Sequence · Fraud · Card · 30d |
5.6 Onboarding and credit lifecycle sequences
| # | Example | Description | Jube construction | Fragment | Notes |
|---|---|---|---|---|---|
| 5.6-01 | Account opened, credit line increased, maxed, no repayment | Bust-out. | TTL Counter LimitIncreaseLast120Days (Data Name AccountId, Interval Days / 120, Sum off) is incremented by the limit-increase rule. TTL Counter RepaymentSumLast120Days (Data Name AccountId, Interval Days / 120, Sum on with Data Value CurrencyAmount) is incremented by the repayment rule. Utilisation (balance over limit) is a placeholder field, and the threshold is a policy value. |
Matched = TTLCounter.LimitIncreaseLast120Days.RequireGreater(0).Against(Payload.Utilisation).ParseDouble().RequireGreaterOrEqual(90).Against(TTLCounter.RepaymentSumLast120Days).MatchIsZero() |
Tag: Sequence · Fraud · Account · 120d |
| 5.6-02 | Multiple accounts opened with same device then all funded same day | Coordinated mule opening. | TTL Counter AccountOpenedByDeviceLast24Hours (Data Name DeviceId, Interval Hours / 24, Sum off) is incremented by the account-opening rule. TTL Counter FundingByDeviceLast24Hours (Data Name DeviceId, Interval Hours / 24, Sum on with Data Value CurrencyAmount) is incremented by the funding rule. The 24-hour window stands in for the same day. The threshold values are placeholders. |
Matched = TTLCounter.AccountOpenedByDeviceLast24Hours.RequireGreaterOrEqual(3).Against(TTLCounter.FundingByDeviceLast24Hours).MatchGreater(50000) |
Tag: Sequence · Fraud · Device · 24h |
| 5.6-03 | KYC failure followed by re-application with altered data | Resubmission after decline. | TTL Counter KycFailLast7Days (Data Name ContactKey, Interval Days / 7, Sum off) is incremented by the KYC-failure rule, where ContactKey is a stable contact or device identifier and a placeholder. Abstraction Rule DistinctDobLast7Days (Search Key ContactKey, Search Interval Days / 7, Function Distinct Count over DateOfBirth) detects altered identity data by counting the distinct dates of birth submitted. |
Matched = TTLCounter.KycFailLast7Days.RequireGreater(0).Against(Abstraction.DistinctDobLast7Days).MatchGreater(1) |
Tag: Sequence · Fraud · Applicant · 7d |
| 5.6-04 | Document upload followed by selfie mismatch followed by new document | Identity spoof iteration. | TTL Counters SelfieMismatchLast24Hours and DocumentUploadLast24Hours (Data Name ApplicantId, Interval Hours / 24, Sum off) are incremented by the selfie-mismatch and document-upload rules. The new-document event reads both, and identity-check events must be fed with the applicant key. |
Matched = TTLCounter.SelfieMismatchLast24Hours.RequireGreater(0).Against(TTLCounter.DocumentUploadLast24Hours).RequireGreater(0).Against(Payload.EventType).MatchEqual("DocumentUpload") |
Tag: Sequence · Fraud · Applicant · 24h |
| 5.6-05 | Contact detail change after application approval | Application then early contact change (takeover of new account). | TTL Counter ApplicationApprovedLast30Days (Data Name AccountId, Interval Days / 30, Sum off) is incremented by the application-approved event, and the contact-change rule reads it. The approval event and the contact-change event must both be fed to Jube. |
Matched = TTLCounter.ApplicationApprovedLast30Days.RequireGreater(0).Against(Payload.EventType).MatchEqual("ContactChange") |
Tag: Sequence · Fraud · Account · 30d |
| 5.6-06 | Credit limit increase request followed by cash advance | Authority then cash-out. | TTL Counter LimitRequestLast48Hours (Data Name AccountId, Interval Hours / 48, Sum off) is incremented by the limit-increase request event, and the cash-advance rule reads it. The request event must be fed. |
Matched = TTLCounter.LimitRequestLast48Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("CashAdvance") |
Tag: Sequence · Fraud · Account · 48h |
| 5.6-07 | Paid-off loan followed by new loan same day with third-party funds | Loan cycling. | TTL Counter LoanPaidOffLast7Days (Data Name CustomerId, Interval Days / 7, Sum off) is incremented by the loan-paid-off event, and the drawdown rule reads it. Third-party funds are approximated by low name similarity between the funder and the customer, using the SimilarityTo string extension. The threshold of 0.5 is a policy value. |
Matched = TTLCounter.LoanPaidOffLast7Days.RequireGreater(0).Against(Payload.EventType).RequireEqual("LoanDrawdown").MatchWhen(Payload.FunderName.SimilarityTo(Payload.CustomerName) < 0.5) |
Tag: Sequence · AML · Account · 7d |
| 5.6-08 | First missed payment on newly opened account | Early default after quick utilisation. | No counter is included. The fragment tests that the missed-payment event falls within 60 days of account opening, using the day count. It does not test that this is the first missed payment; a TTL Counter of prior missed payments read with MatchIsZero() would add that. DaysSinceAccountOpened is a placeholder field, the whole days since account opening computed upstream and held as text, because date-to-date comparison needs a typed date argument. |
Matched = Payload.EventType.RequireEqual("MissedPayment").Against(Payload.DaysSinceAccountOpened).ParseDouble().MatchInRange(0, 60) |
Tag: Sequence · Fraud · Account · 60d |
5.7 Dormancy, state-change and lifecycle states
| # | Example | Description | Jube construction | Fragment | Notes |
|---|---|---|---|---|---|
| 5.7-01 | Dormant → active → large outflow | State transition from dormant then movement. | TTL Counter Activity12Months (Data Name AccountId, Interval Months / 12, code m, Sum off) is incremented by every account event. The reactivation rule’s increment condition is the first activity after twelve months of zero activity, read with MatchIsZero() before this event is counted, so it is a conditional increment. TTL Counter ReactivationLast7Days (Data Name AccountId, Interval Days / 7) is read by the outflow rule. The threshold of 9000 is a placeholder. |
Matched = TTLCounter.ReactivationLast7Days.RequireGreater(0).Against(Payload.CurrencyAmount).RequireGreater(9000).Against(Payload.EventType).MatchEqual("Outflow") |
Check: 12-month dormancy is a policy choice; statutory unclaimed-funds dormancy differs by jurisdiction. Tag: Sequence · AML · Account · 12m dormancy |
| 5.7-02 | Account closed then reopened under variations | Reapplication after closure. | TTL Counter AccountClosedLast90Days (Data Name CustomerId, Interval Days / 90, Sum off) is incremented by the account-closed rule. Abstraction Rule NameVariantsLast90Days (Search Key CustomerId, Search Interval Days / 90, Function Distinct Count over NormalisedName) counts the name variants applied. The customer key must be stable across applications, and NormalisedName is normalised upstream. |
Matched = TTLCounter.AccountClosedLast90Days.RequireGreater(0).Against(Payload.EventType).RequireEqual("AccountOpen").Against(Abstraction.NameVariantsLast90Days).MatchGreater(1) |
Tag: Sequence · Fraud · Applicant · 90d |
| 5.7-03 | Account restriction lifted followed by high-value transfer | Post-block activity. | TTL Counter RestrictionLiftedLast7Days (Data Name AccountId, Interval Days / 7, Sum off) is incremented by the restriction-lifted event, and the transfer rule reads it. The restriction-lifted event must be fed. The threshold of 9000 is a placeholder. |
Matched = TTLCounter.RestrictionLiftedLast7Days.RequireGreater(0).Against(Payload.CurrencyAmount).RequireGreater(9000).Against(Payload.EventType).MatchEqual("Transfer") |
Tag: Sequence · Fraud · Account · 7d |
| 5.7-04 | Alert disposition “false positive” followed by repeat pattern | Pattern persists after clearance. | TTL Counter AlertFalsePositiveLast30Days (Data Name CustomerId, Interval Days / 30, Sum off) is incremented by the alert-disposition event, and TTL Counter PatternHitLast30Days (Data Name CustomerId, Interval Days / 30, Sum off) is incremented by the pattern rule. Both must be fed, and the order between them is co-occurrence. |
Matched = TTLCounter.AlertFalsePositiveLast30Days.RequireGreater(0).Against(TTLCounter.PatternHitLast30Days).MatchGreater(0) |
Tag: Sequence · Both · Account · 30d |
| 5.7-05 | Customer on watch list followed by new product opening | Opening products while under review. | Sanction definition CustomerWatchList names the customer name field as its multipart string, and the engine makes its distance available as Sanction.CustomerWatchList before rules run. The product-opening rule reads it. This checks watch-list status at the opening, and a prior-hit history is not kept, so the order is approximated. The distance of 1 is a placeholder. |
Matched = Sanction.CustomerWatchList.RequireLessOrEqual(1).Against(Payload.EventType).MatchEqual("ProductOpen") |
Tag: Sequence · AML · Customer · 90d |
| 5.7-06 | SAR filed followed by continuing activity | Continued activity after report. | TTL Counter SarFiledLast90Days (Data Name CustomerId, Interval Days / 90, Sum off) is incremented by the SAR-filed event, and the transaction rule reads it. The SAR event is internal case data and must never reach customer-facing or front-line outputs. |
Matched = TTLCounter.SarFiledLast90Days.RequireGreater(0).Against(Payload.EventType).MatchEqual("Transaction") |
Check: SAR confidentiality and tipping-off rules apply under the relevant regime; compliance must confirm the feedback loop. Tag: Sequence · AML · Customer · 90d |
| 5.7-07 | Enhanced due diligence expiry followed by high-risk transaction | Review lapses then risky activity. | No counter is included. The rule tests that the review has lapsed by between 0 and 30 days, then checks the amount. ReferenceDate and EddExpiryDate are placeholder date fields, and the date methods compare them directly, so the date is not parsed. The 30-day window and the amount are placeholders. |
Matched = Payload.ReferenceDate.RequireMoreThanDaysAfter(Payload.EddExpiryDate, 0).Against(Payload.ReferenceDate).RequireWithinDaysOf(Payload.EddExpiryDate, 30).Against(Payload.CurrencyAmount).MatchGreater(5000) |
Check: EDD review cycles and the 30-day lapse window are internal or regulatory settings; verify with compliance. Tag: Sequence · AML · Customer · 30d |
5.8 Scam-specific sequences (expanded)
| # | Example | Description | Jube construction | Fragment | Notes |
|---|---|---|---|---|---|
| 5.8-01 | Impersonation (bank/police) sequence | Inbound call signal or customer report → payment to “safe account” new payee → further payments. | TTL Counter ImpersonationCallLast24Hours (Data Name CustomerId, Interval Hours / 24, Sum off) is incremented by the inbound-call signal rule. TTL Counter PayeeSeenLast365Days (Data Name PayeeId, Interval Days / 365, Sum off) is incremented by the payment rule, which must have the lower Priority number so the count includes the current payment. The inbound call signal must be fed to Jube, and the safe-account label is a payee reference or list entry. |
Matched = TTLCounter.ImpersonationCallLast24Hours.RequireGreater(0).Against(TTLCounter.PayeeSeenLast365Days).RequireLessOrEqual(1).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 24h |
| 5.8-02 | Investment scam sequence | Small initial payment to new payee → “returns” credited → much larger payments → crypto exchange. | TTL Counter PayeeSeenLast60Days (Data Name PayeeId, Interval Days / 60, Sum off) is incremented by the payment rule, whose Priority number must be lower so the count includes the current payment. TTL Counter PayeeInboundLast60Days (Data Name PayeeId, Interval Days / 60, Sum off) is incremented by inbound credits from the same payee, which are the returns. The crypto test uses the List CryptoExchanges. The amount threshold is a placeholder. |
Matched = TTLCounter.PayeeSeenLast60Days.RequireLessOrEqual(1).Against(TTLCounter.PayeeInboundLast60Days).RequireGreater(0).Against(Payload.CurrencyAmount).RequireGreater(5000).Against(Payload.PayeeName).MatchNormalisedInList(List.CryptoExchanges) |
Tag: Sequence · Fraud · Account · 60d |
| 5.8-03 | Purchase scam sequence | Marketplace browsing referral → payment to individual payee → no further activity with payee. | TTL Counter MarketplaceReferralLast7Days (Data Name CustomerId, Interval Days / 7, Sum off) is incremented by the marketplace-referral event. TTL Counter PayeeSeenLast7Days (Data Name PayeeId, Interval Days / 7, Sum off) is incremented by the payment rule, whose Priority number must be lower so the count includes the current payment. The no-further-activity test is a later check on TTL Counter PayeeActivityLast7Days (Data Name PayeeId) equal to 1, not a payment-time test. |
Matched = TTLCounter.MarketplaceReferralLast7Days.RequireGreater(0).Against(TTLCounter.PayeeSeenLast7Days).RequireLessOrEqual(1).Against(Payload.PayeeType).MatchEqual("Individual") |
Tag: Sequence · Fraud · Account · 7d |
| 5.8-04 | Advance-fee sequence | Series of small escalating payments labelled fees to overseas payee. | Abstraction Rule PayeeMaxAmountLast30Days (Search Key PayeeId, Search Interval Days / 30, Function Max over CurrencyAmount) holds the largest prior payment to the payee. TTL Counter FeePaymentsLast30Days (Data Name PayeeId, Interval Days / 30, Sum off) is incremented by the payment rule. This is a proxy for escalation, testing a new high, not strict escalation, and the fee labelling is not tested. The count and threshold are placeholders. |
Matched = Payload.CurrencyAmount.RequireGreater(Abstraction.PayeeMaxAmountLast30Days).Against(TTLCounter.FeePaymentsLast30Days).RequireGreaterOrEqual(3).MatchWhen(Payload.PayeeCountry.CountryAlpha2() <> Payload.ResidenceCountry.CountryAlpha2()) |
Tag: Sequence · Fraud · Account · 30d |
| 5.8-05 | Job scam sequence | Inbound credit from unknown company → immediate onward transfer (mule onboarding). | TTL Counter InboundCreditLast48Hours (Data Name AccountId, Interval Hours / 48, Sum on with Data Value CurrencyAmount) is incremented by the inbound-credit rule. The outbound rule reads the count and tests that the outbound amount is within 10 percent of the credited total, and that the payer is not on the maintained List KnownEmployers, using Not because a payer not on the list is the signal. List completeness is the limit. |
Matched = TTLCounter.InboundCreditLast48Hours.RequireGreater(0).Against(Payload.CurrencyAmount).RequireWithinPercentOf(TTLCounter.InboundCreditLast48Hours, 10).Against(Payload.EventType).RequireEqual("Outbound").Against(Payload.PayerName).RejectNormalisedInList(List.KnownEmployers).OtherwiseMatch() |
Tag: Sequence · Both · Account · 48h |
| 5.8-06 | Rental scam sequence | Deposit payment to new personal payee shortly after classified-ad referral. | TTL Counter ClassifiedAdReferralLast7Days (Data Name CustomerId, Interval Days / 7, Sum off) is incremented by the classified-ad referral event. The payment rule reads it together with TTL Counter PayeeSeenLast365Days (the counter from 5.2-01, Data Name PayeeId, Interval Days / 365), whose Priority number must be lower so the count includes the current payment. The referral source must be fed as an event. |
Matched = TTLCounter.ClassifiedAdReferralLast7Days.RequireGreater(0).Against(TTLCounter.PayeeSeenLast365Days).RequireLessOrEqual(1).Against(Payload.PayeeType).RequireEqual("Individual").Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 7d |
| 5.8-07 | Family emergency (“hi mum”) sequence | Payment to new personal payee after SMS/WhatsApp signal; often the first payment to that payee and high urgency. | TTL Counter MessagingSignalLastHour (Data Name CustomerId, Interval Hours / 1, Sum off) is incremented by the messaging-signal event, and the payment rule reads it together with PayeeSeenLast365Days from 5.2-01, whose Priority number must be lower. The messaging signal must be fed to Jube, and its origin determines whether it is in-bank. |
Matched = TTLCounter.MessagingSignalLastHour.RequireGreater(0).Against(TTLCounter.PayeeSeenLast365Days).RequireLessOrEqual(1).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 1h |
| 5.8-08 | Courier/parcel scam sequence | Small “redelivery fee” card payment → larger CNP fraud on the card. | TTL Counter SmallCardPaymentLast72Hours (Data Name CardId, Interval Hours / 72, Sum off) is incremented by a card-payment rule whose condition is an amount under the small threshold. Abstraction Rule CardMinimumLast72Hours (Search Key CardId, Search Interval Hours / 72, Function Min over CurrencyAmount) holds the smallest amount. The large card-not-present payment is then tested. Thresholds are placeholders. |
Matched = TTLCounter.SmallCardPaymentLast72Hours.RequireGreater(0).Against(Abstraction.CardMinimumLast72Hours).RequireLess(5).Against(Payload.CurrencyAmount).RequireGreater(500).Against(Payload.EntryMode).MatchEqual("CardNotPresent") |
Tag: Sequence · Fraud · Card · 72h |
| 5.8-09 | Pig-butchering sequence | Long inactive relationship → small crypto buy → escalating buys → attempt to withdraw funds elsewhere. | TTL Counter CryptoBuyLast90Days (Data Name AccountId, Interval Days / 90, Sum off) is incremented by the crypto-buy rule, whose condition is a payment to the List CryptoExchanges. Abstraction Rule CryptoBuyMaxLast90Days (Search Key AccountId, Search Interval Days / 90, Function Max over CurrencyAmount) holds the largest prior buy, and the abstraction window must exclude the current payment. This is a proxy for escalating buys. The long-inactivity test before the first buy is not included, and needs an activity-zero counter as in 5.2-07. |
Matched = TTLCounter.CryptoBuyLast90Days.RequireGreaterOrEqual(3).Against(Payload.CurrencyAmount).RequireGreater(Abstraction.CryptoBuyMaxLast90Days).Against(Payload.PayeeName).MatchNormalisedInList(List.CryptoExchanges) |
Tag: Sequence · Fraud · Account · 90d |
| 5.8-10 | Subscription trap sequence | Trial charge → recurring charges → disputes. | TTL Counter RecurringChargeLast60Days (Data Name CardMerchantKey, Interval Days / 60, Sum off) is incremented by the recurring-charge rule, and TTL Counter DisputeLast60Days (Data Name CardMerchantKey, Interval Days / 60, Sum off) is incremented by the dispute rule. The subscription rule reads both. CardMerchantKey is a composite key built upstream. |
Matched = TTLCounter.RecurringChargeLast60Days.RequireGreaterOrEqual(2).Against(TTLCounter.DisputeLast60Days).MatchGreater(0) |
Check: Dispute windows are set by card schemes; verify 60d. Tag: Sequence · Fraud · Card · 60d |
| 5.8-12 | Charity scam sequence | Donation to new payee following disaster news; repeated. | TTL Counter PayeeSeenLast7Days (Data Name PayeeId, Interval Days / 7, Sum off) is incremented by the payment rule, whose Priority number must be lower so the count includes the current payment. The List DisasterAppealCharities is curated from news, so its currency is the limit. |
Matched = TTLCounter.PayeeSeenLast7Days.RequireLessOrEqual(1).Against(Payload.PayeeName).RequireNormalisedInList(List.DisasterAppealCharities).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 7d |
| 5.8-13 | Refund scam sequence | Inbound erroneous “overpayment” → customer sends “difference” to scammer. | TTL Counter OverpaymentInLast24Hours (Data Name AccountId, Interval Hours / 24, Sum on with Data Value CurrencyAmount) is incremented by the inbound-overpayment rule. The outbound payment is bounded by that inbound sum. TTL Counter PayeeSeenLast365Days (Data Name PayeeId) is incremented by the payment rule, whose Priority number must be lower so the count includes the current payment. |
Matched = TTLCounter.OverpaymentInLast24Hours.RequireGreater(0).Against(Payload.CurrencyAmount).RequireLessOrEqual(TTLCounter.OverpaymentInLast24Hours).Against(TTLCounter.PayeeSeenLast365Days).RequireLessOrEqual(1).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Account · 24h |
| 5.8-14 | Recovery-room scam sequence | Victim of prior scam makes payment to “recovery agent” payee. | TTL Counter PriorScamVictimLast90Days (Data Name CustomerId, Interval Days / 90, Sum off) is incremented by the prior-scam flag, which must be fed from case data or prior payments. TTL Counter PayeeSeenLast365Days (Data Name PayeeId) is incremented by the payment rule, whose Priority number must be lower. The List RecoveryAgentNames is maintained reference data. |
Matched = TTLCounter.PriorScamVictimLast90Days.RequireGreater(0).Against(TTLCounter.PayeeSeenLast365Days).RequireLessOrEqual(1).Against(Payload.PayeeName).MatchNormalisedInList(List.RecoveryAgentNames) |
Tag: Sequence · Fraud · Account · 90d |
| 5.8-15 | Overpayment cheque scam sequence | Cheque deposit → outbound transfer → cheque returned unpaid. | TTL Counters ChequeDepositLast10Days and OutboundTransferLast10Days (Data Name AccountId, Interval Days / 10, Sum off) are incremented by the cheque-deposit and outbound-transfer rules. The cheque-return event reads both, so the alert fires when the return arrives, and the order of the prior steps is co-occurrence only. |
Matched = TTLCounter.ChequeDepositLast10Days.RequireGreater(0).Against(TTLCounter.OutboundTransferLast10Days).RequireGreater(0).Against(Payload.EventType).MatchEqual("ChequeReturned") |
Check: Cheque return and clearing timeframes differ by jurisdiction; verify 10d. Tag: Sequence · Fraud · Account · 10d |
| 5.8-16 | Ticket scam sequence | Payment to individual payee near event date. | No counter is included. The test is that the payment date falls within 7 days of the event date, using the WithinDaysOf step on a date, with the payee type restricted to individuals. The plain DateTime form of this test does not exist; the pipeline step is the one used. PaymentDate and EventDate are placeholder fields. |
Matched = Payload.PaymentDate.RequireWithinDaysOf(Payload.EventDate, 7).Against(Payload.PayeeType).MatchEqual("Individual") |
Tag: Sequence · Fraud · Account · 7d |
| 5.8-17 | Crypto giveaway scam sequence | Small outbound crypto transfer to address promising doubling. | A List GiveawayScamAddresses holds the addresses that promise a doubling, from the analytics feed. MatchInList is an exact match, not MatchNormalisedInList, because addresses are case sensitive and folding would change them. The amount threshold is a placeholder. The crypto-transfer event is a placeholder name. |
Matched = Payload.DestinationAddress.RequireInList(List.GiveawayScamAddresses).Against(Payload.CurrencyAmount).RequireLess(100).Against(Payload.EventType).MatchEqual("CryptoTransfer") |
Tag: Sequence · Fraud · Wallet · 24h |
5.9 Sector-specific sequences
| # | Example | Description | Jube construction | Fragment | Notes |
|---|---|---|---|---|---|
| 5.9-01 | Policy inception → claim → cancellation (insurance) | Short-lived policy used for one claim. | TTL Counters PolicyInceptionLast90Days and ClaimLast90Days (Data Name PolicyId, Interval Days / 90, Sum off) are incremented by the policy-inception and claim events, and the policy-cancel rule reads both. Insurer or policy events must be fed to Jube. |
Matched = TTLCounter.PolicyInceptionLast90Days.RequireGreater(0).Against(TTLCounter.ClaimLast90Days).RequireGreater(0).Against(Payload.EventType).MatchEqual("PolicyCancel") |
Tag: Sequence · Fraud · Policy · 90d |
| 5.9-02 | Premium overpayment → refund request to third party | Insurance used for layering. | TTL Counter PremiumOverpaymentLast30Days (Data Name PolicyId, Interval Days / 30, Sum off) is incremented by the premium-overpayment rule. The refund rule reads it and tests the payee against the policy holder by low name similarity, which approximates a third-party refund. The threshold of 0.5 is a policy value. |
Matched = TTLCounter.PremiumOverpaymentLast30Days.RequireGreater(0).Against(Payload.EventType).RequireEqual("Refund").MatchWhen(Payload.PayeeName.SimilarityTo(Payload.PolicyHolderName) < 0.5) |
Tag: Sequence · AML · Policy · 30d |
| 5.9-03 | Beneficiary change → death claim within short window | Beneficiary manipulation. | TTL Counter BeneficiaryChangeLast180Days (Data Name PolicyId, Interval Days / 180, Sum off) is incremented by the beneficiary-change rule, and the claim rule reads it when the claim type is death. This is sensitive data, so output must be restricted accordingly. |
Matched = TTLCounter.BeneficiaryChangeLast180Days.RequireGreater(0).Against(Payload.ClaimType).MatchEqual("Death") |
Tag: Sequence · Fraud · Policy · 180d |
| 5.9-04 | Policy loan → default → surrender | Value extraction. | TTL Counters PolicyLoanLast12Months and LoanDefaultLast12Months (Data Name PolicyId, Interval Months / 12, code m, Sum off) are incremented by the policy-loan and loan-default rules, and the surrender rule reads both. Twelve months is a Months interval, not days. |
Matched = TTLCounter.PolicyLoanLast12Months.RequireGreater(0).Against(TTLCounter.LoanDefaultLast12Months).RequireGreater(0).Against(Payload.EventType).MatchEqual("Surrender") |
Tag: Sequence · AML · Policy · 12m |
| 5.9-05 | Deposit → minimal play → withdrawal (gaming) | Casino account as pass-through. | TTL Counters GamingWagerSumLast24Hours and GamingDepositSumLast24Hours (Data Name PlayerId, Interval Hours / 24, Sum on with Data Value CurrencyAmount) are incremented by the wager and deposit rules. The withdrawal rule reads the wager total as a percentage of the deposit total, using the PercentOf calculation. The gaming platform feed is required, and 10 percent is a policy value. |
Matched = TTLCounter.GamingWagerSumLast24Hours.PercentOf(TTLCounter.GamingDepositSumLast24Hours).RequireLess(10).Against(Payload.EventType).MatchEqual("Withdrawal") |
Tag: Sequence · AML · Player · 24h |
| 5.9-06 | Bonus claimed → minimum wagering → withdrawal | Bonus abuse. | TTL Counter BonusClaimLast7Days (Data Name PlayerId, Interval Days / 7, Sum off) is incremented by the bonus-claim rule. TTL Counter GamingWagerSumLast7Days (Data Name PlayerId, Interval Days / 7, Sum on with Data Value CurrencyAmount) is incremented by the wager rule. The withdrawal rule reads both and tests that wagering has reached the operator’s requirement, which is a placeholder value. |
Matched = TTLCounter.BonusClaimLast7Days.RequireGreater(0).Against(TTLCounter.GamingWagerSumLast7Days).RequireGreaterOrEqual(5000).Against(Payload.EventType).MatchEqual("Withdrawal") |
Check: Bonus wagering conditions are set by the operator and may be subject to gaming-regulator rules; verify. Tag: Sequence · Fraud · Player · 7d |
| 5.9-07 | Large losses to one opponent → that opponent withdraws | Chip dumping transfer. | TTL Counter LossesReceivedLast24Hours (Data Name WinnerId, Interval Hours / 24, Sum on with Data Value CurrencyAmount) is incremented by the loss rule, keyed on the winner, so it aggregates losses from every counterparty rather than one pair. A pair key would need a composite upstream. The threshold of 50000 is a placeholder. |
Matched = TTLCounter.LossesReceivedLast24Hours.RequireGreater(50000).Against(Payload.EventType).MatchEqual("Withdrawal") |
Tag: Sequence · AML · Player pair · 24h |
| 5.9-08 | Deposit → buy security → transfer out via ACATS (brokerage) | Securities used to move value. | TTL Counters DepositSumLast14Days (Sum on with Data Value CurrencyAmount) and SecurityBuyLast14Days (count), both with Data Name AccountId and Interval Days / 14, are incremented by the deposit and security-buy rules. The ACATS transfer-out rule reads both, and the transfer-out event must be fed with the transfer method. |
Matched = TTLCounter.DepositSumLast14Days.RequireGreater(0).Against(TTLCounter.SecurityBuyLast14Days).RequireGreater(0).Against(Payload.EventType).MatchEqual("AcatsTransferOut") |
Check: ACATS is a US brokerage account transfer system; the rule applies only where it exists, so verify jurisdiction. Tag: Sequence · AML · Account · 14d |
| 5.9-10 | Deposit → convert to stablecoin → withdraw to unhosted wallet (crypto) | Rapid chain. | Single event. The destination wallet’s custody status is supplied upstream as DestinationWalletType (placeholder). The Travel Rule obligation itself varies by jurisdiction and is not encoded here. | Matched = Payload.DestinationWalletType.MatchEqual("Unhosted") |
Tag: Sequence · AML · Account · 2h |
| 5.9-11 | Fiat buy → bridge → mixer → withdraw | Obfuscation chain. | TTL Counter FiatBuyLast24Hours (Data Name CustomerId, Interval Hours / 24, Sum off) is incremented by the fiat-buy rule. The crypto-withdrawal rule reads it and tests the destination address against the maintained List MixerAndBridgeAddresses, using MatchInList because addresses are case sensitive. The bridge and mixer addresses are reference data from the analytics feed. |
Matched = TTLCounter.FiatBuyLast24Hours.RequireGreater(0).Against(Payload.DestinationAddress).RequireInList(List.MixerAndBridgeAddresses).Against(Payload.EventType).MatchEqual("CryptoWithdrawal") |
Tag: Sequence · AML · Wallet · 24h |
| 5.9-12 | Deposit from flagged address → swap → withdraw | Tainted-funds laundering. | TTL Counter FlaggedDepositLast24Hours (Data Name CustomerId, Interval Hours / 24, Sum off) is incremented by the deposit rule, whose own condition is that SourceAddress matches the vendor-fed List FlaggedAddresses with MatchInList, so the flag sits on the deposit’s source address. TTL Counter SwapLast24Hours (Data Name CustomerId, Interval Hours / 24, Sum off) is incremented by the swap rule. The withdrawal rule reads both. |
Matched = TTLCounter.FlaggedDepositLast24Hours.RequireGreater(0).Against(TTLCounter.SwapLast24Hours).RequireGreater(0).Against(Payload.EventType).MatchEqual("Withdrawal") |
Tag: Sequence · AML · Account · 24h |
| 5.9-14 | Agent cash-in → wallet-to-wallet → different agent cash-out | Agent-assisted structuring. | TTL Counter AgentCashInLast24Hours (Data Name WalletId, Interval Hours / 24, Sum off) is incremented by the agent cash-in rule. Abstraction Rule DistinctAgentsLast24Hours (Search Key WalletId, Search Interval Hours / 24, Function Distinct Count over AgentId) counts the agents used. Agent identifiers must be fed on both legs. |
Matched = TTLCounter.AgentCashInLast24Hours.RequireGreater(0).Against(Payload.EventType).RequireEqual("AgentCashOut").Against(Abstraction.DistinctAgentsLast24Hours).MatchGreater(1) |
Tag: Sequence · AML · Wallet · 24h |
| 5.9-15 | Vendor bank change → urgent payment → vendor dispute (corporate) | Invoice redirection realised. | TTL Counter VendorBankChangeLast30Days (Data Name VendorId, Interval Days / 30, Sum off) is incremented by the vendor bank-detail change event, and the urgent-payment rule reads it. The dispute is a later event. Urgency is a placeholder field. |
Matched = TTLCounter.VendorBankChangeLast30Days.RequireGreater(0).Against(Payload.EventType).RequireEqual("Payment").Against(Payload.Urgency).MatchEqual("Urgent") |
Tag: Sequence · Fraud · Vendor · 30d |
| 5.9-16 | New user entitlement → payment file → user removed | Insider one-shot. | TTL Counters UserAddedLast7Days and PaymentFileLast7Days (Data Name ClientId, Interval Days / 7, Sum off) are incremented by the user-added and payment-file rules, and the user-removed rule reads both. The entitlement and payment-file events must be fed with the client key. |
Matched = TTLCounter.UserAddedLast7Days.RequireGreater(0).Against(TTLCounter.PaymentFileLast7Days).RequireGreater(0).Against(Payload.EventType).MatchEqual("UserRemoved") |
Tag: Sequence · Fraud · Account · 7d |
| 5.9-17 | Employee leaves → still receives payroll | Leaver not removed. | The payroll pay date falls after the employment end date. Upstream fields: Payload.PayDate and Payload.EmploymentEndDate, supplied before Jube or by an inline-script hook. Both are dates. | Matched = Payload.PayDate.MatchAfter(Payload.EmploymentEndDate) |
Tag: Sequence · Fraud · Employee · 60d |
| 5.9-18 | Order → shipping address change → delivery (e-commerce) | Post-order address switch. | TTL Counter AddressChangeLast24Hours (Data Name OrderId, Interval Hours / 24, Sum off) is incremented by the shipping-address change rule, and the delivery rule reads it. The order key must be shared by the address-change and delivery events. |
Matched = TTLCounter.AddressChangeLast24Hours.RequireGreater(0).Against(Payload.EventType).MatchEqual("Delivery") |
Tag: Sequence · Fraud · Order · 24h |
| 5.9-19 | Order → item not received claim → reorder same item | INR abuse. | TTL Counter NotReceivedClaimLast30Days (Data Name AccountId, Interval Days / 30, Sum off) is incremented by the not-received claim rule. TTL Counter OrdersLast30Days (Data Name AccountId, Interval Days / 30, Sum off) is incremented by each order. Abstraction Rule DistinctItemsLast30Days (Search Key AccountId, Search Interval Days / 30, Function Distinct Count over ItemSku) must equal 1, meaning the same item across the orders. |
Matched = TTLCounter.NotReceivedClaimLast30Days.RequireGreater(0).Against(Abstraction.DistinctItemsLast30Days).RequireEqual(1).Against(TTLCounter.OrdersLast30Days).MatchGreaterOrEqual(2) |
Tag: Sequence · Fraud · Account · 30d |
| 5.9-20 | Return initiated → refund issued → item never received by merchant | Return fraud. | Refund event where the merchant has not received the returned item. Upstream field: Payload.ReturnReceivedFlag, supplied before Jube or by an inline-script hook. Attach the test to refund events only; the TTL Counter of returns initiated (Data Name OrderId, Interval Days 30) is a separate rule and is not part of this fragment. | Matched = Payload.ReturnReceivedFlag.MatchIsFalse() |
Tag: Sequence · Fraud · Account · 30d |
| 5.9-21 | Loan funded → full repayment within days by third party → new larger loan | Credit building for bust-out or laundering. | TTL Counters LoanFundedLast60Days and ThirdPartyRepaymentLast60Days (Data Name CustomerId, Interval Days / 60, Sum off) are incremented by the loan-funded and third-party-repayment rules. The repayment rule’s condition is that the payer differs from the borrower, a conditional increment. Abstraction Rule PriorLoanMaxLast60Days (Search Key CustomerId, Search Interval Days / 60, Function Max over LoanAmount) holds the largest prior loan, and the drawdown rule compares the new loan with it. This is a proxy for larger than the previous loan. |
Matched = TTLCounter.LoanFundedLast60Days.RequireGreater(0).Against(TTLCounter.ThirdPartyRepaymentLast60Days).RequireGreater(0).Against(Payload.EventType).RequireEqual("LoanDrawdown").Against(Payload.LoanAmount).MatchGreater(Abstraction.PriorLoanMaxLast60Days) |
Tag: Sequence · Both · Customer · 60d |
| 5.9-23 | Remittance received → cash-out → immediate send to third corridor | Pass-through via MSB. | TTL Counter RemittanceInLast24Hours (Data Name ReceiverId, Interval Hours / 24, Sum off) is incremented by the remittance-receipt rule. Abstraction Rule CorridorsLast24Hours (Search Key ReceiverId, Search Interval Hours / 24, Function Distinct Count over CorridorCountry) counts the corridors used on each leg. The send rule reads both. Money-service-business obligations vary by jurisdiction. |
Matched = TTLCounter.RemittanceInLast24Hours.RequireGreater(0).Against(Payload.EventType).RequireEqual("RemittanceSend").Against(Abstraction.CorridorsLast24Hours).MatchGreaterOrEqual(3) |
Check: Money-service-business obligations vary by jurisdiction; verify. Tag: Sequence · AML · Receiver · 24h |
| 5.9-24 | Cheque deposit → withdrawal before clearing → cheque bounces | Cheque kiting. | TTL Counters ChequeDepositLast5Days and WithdrawalPreClearingLast5Days (Data Name AccountId, Interval Days / 5, Sum off) are incremented by the cheque-deposit and pre-clearing withdrawal rules, and the cheque-return rule reads both. The alert fires when the bounce arrives. Cheque clearing periods differ by jurisdiction. |
Matched = TTLCounter.ChequeDepositLast5Days.RequireGreater(0).Against(TTLCounter.WithdrawalPreClearingLast5Days).RequireGreater(0).Against(Payload.EventType).MatchEqual("ChequeReturned") |
Check: Cheque clearing periods differ by jurisdiction; verify 5d. Tag: Sequence · Fraud · Account · 5d |
5.10 Staff and insider sequences
| # | Example | Description | Jube construction | Fragment | Notes |
|---|---|---|---|---|---|
| 5.10-01 | Employee views account → contact detail changed → payment | Insider-facilitated takeover. | TTL Counters EmployeeViewLast24Hours and ContactChangeLast24Hours (Data Name AccountId, Interval Hours / 24, Sum off) are incremented by the employee-view and contact-change rules, and the payment rule reads both. The employee access-log events must be fed to Jube. |
Matched = TTLCounter.EmployeeViewLast24Hours.RequireGreater(0).Against(TTLCounter.ContactChangeLast24Hours).RequireGreater(0).Against(Payload.EventType).MatchEqual("Payment") |
Tag: Sequence · Fraud · Employee/Account · 24h |
| 5.10-02 | Employee access outside role → data export | Data exfiltration path. | A List PermittedRoleResources holds the allowed role and resource pairs, and the RoleResourceKey field is a placeholder composite of role and resource built upstream. The rule is a single-event test that is true when the pair is not in the list, using Not, which is true for every case except a matched pipeline. |
Matched = Payload.EventType.RequireEqual("DataExport").Against(Payload.RoleResourceKey).RejectInList(List.PermittedRoleResources).OtherwiseMatch() |
Tag: Sequence · Fraud · Employee · 24h |
| 5.10-03 | Limit override by staff → high-value payment → override reverted | Temporary bypass. | TTL Counter LimitOverrideLast24Hours (Data Name AccountId, Interval Hours / 24, Sum off) is incremented by the limit-override event. The high-value payment rule reads it. The reversion is checked by a second rule, and the limit of 9000 is a placeholder. |
Matched = TTLCounter.LimitOverrideLast24Hours.RequireGreater(0).Against(Payload.EventType).RequireEqual("Payment").Against(Payload.CurrencyAmount).MatchGreater(9000) |
Tag: Sequence · Fraud · Employee · 24h |
| 5.10-04 | Alert closed quickly by analyst → same pattern repeats → closed by same analyst | Analyst collusion/negligence. | TTL Counter QuickCloseLast90Days (Data Name AnalystId, Interval Days / 90, Sum off) is incremented by an alert-closure rule whose condition is a closure under the time threshold, a conditional increment. The analyst identifier is the key. The threshold of 5 is a placeholder for N. |
Matched = TTLCounter.QuickCloseLast90Days.MatchGreaterOrEqual(5) |
Tag: Sequence · Both · Analyst · 90d |
| 5.10-05 | Dormant account accessed by staff → reactivated → outflow | Insider dormant account abuse. | TTL Counter StaffAccessDormantLast7Days (Data Name AccountId, Interval Days / 7, Sum off) is incremented by a staff-access rule whose condition is that the account is dormant, using the dormancy test in 5.1-10. The outflow rule reads it. The dormancy period is a policy choice. |
Matched = TTLCounter.StaffAccessDormantLast7Days.RequireGreater(0).Against(Payload.EventType).MatchEqual("Outflow") |
Check: Dormancy period is a policy choice. Tag: Sequence · Fraud · Employee · 7d |
| 5.10-06 | Cash drawer shortage after void sequence | Till fraud. | TTL Counter VoidLastDay (Data Name CashierId, Interval Days / 1, Sum off) is incremented by the void rule. The drawer-variance field comes from till reconciliation, and the count and tolerance are placeholder policy values. |
Matched = TTLCounter.VoidLastDay.RequireGreaterOrEqual(3).Against(Payload.DrawerVariance).ParseDouble().MatchLess(-20) |
Tag: Sequence · Fraud · Cashier · 1d |