Skip to main content

Monitoring rules

Monitoring rules give you in-life monitoring of a customer: instead of asking "what do this customer's transactions look like right now?", a rule watches a customer's transaction history over time and tells you when something you care about happens - for example a sustained drop in turnover, a spike in dishonoured payments, or a new counterparty appearing.

Unlike a report, which you pull on demand, a monitoring rule is evaluated automatically as new data arrives and notifies you - via a webhook - only when it triggers.

Defining a rule​

Monitoring rules are not self-service. Each rule is defined in collaboration with Walker Street Data so it matches how you actually make decisions:

  • the signal it watches (for example turnover, dishonours, or a specific classification),
  • the thresholds that count as a trigger, and
  • the scope - which customers or portfolio the rule applies to.

Walker Street Data implements and activates the rule against your client account. To set one up, contact us with what you want to monitor and how you'd like to be alerted.

Once a rule is active there is nothing further to configure on the rule itself - the remaining steps (subscribing and handling notifications) use the standard webhook API.

How rules run​

Rules evaluate automatically off the back of transaction processing - there is no separate call to trigger them:

  1. Submit transactions (or a PDF) for a customer. You receive a jobId.
  2. The job enriches the transactions. Once enrichment completes, every active rule that applies to that customer is evaluated.
  3. Evaluation looks at the customer's previous 12 months of enriched transactions, ending on the run date - so a rule reflects a rolling one-year window of history, not just the transactions in the latest submission.
  4. Each evaluation is recorded. When a rule's condition is met, a monitoring.rule.triggered webhook is delivered to your matching subscriptions. If the condition is not met, no webhook is sent.

Because evaluation is anchored to enrichment, keeping a customer's transactions up to date is what keeps their monitoring current. Submitting more transactions later re-evaluates the rules over the refreshed 12-month window.

Getting notified​

Notifications are delivered through the standard webhook mechanism. Create a subscription for the monitoring.rule.triggered event type, pointing at your HTTPS endpoint:

curl -X POST "https://api.walkerstdata.com.au/v1/webhooks/subscriptions" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "eventType": "monitoring.rule.triggered",
    "webhookUrl": "https://your-app.example.com/webhooks/wsd",
    "customerIds": []
  }'

A single subscription receives triggers for all monitoring rules on your account. To limit delivery to specific customers, provide their IDs in customerIds; an empty list is a catch-all. See Webhooks - scoping to customers for the full subscription, signature-verification, and delivery-behaviour details.

The trigger payload​

A monitoring.rule.triggered delivery carries the common webhook envelope (eventType, eventId, clientId, customerId, timestamp) plus the fields below. Note it does not include the job-specific fields (jobId, abn, jobType) - a trigger is tied to a customer and a rule, not a single job.

FieldTypeDescription
evaluationResultIduuidIdentifier for this evaluation result
monitoringRuleIduuidThe rule that triggered
ruleNamestringHuman-readable name of the rule
runDatestring (ISO date)The date the rule was evaluated; the 12-month window ends here
interpretationstring[]Human-readable explanation of why the rule triggered
recommendedActionstring[]Suggested follow-up action(s)

Example delivery:

{
  "eventType": "monitoring.rule.triggered",
  "eventId": "b2c3d4e5-f6a7-8901-bcde-f23456789012",
  "clientId": "a0ced7e1-da3a-40ea-a18f-4c829f816c6a",
  "customerId": "524ba9bc-06e7-417e-bd54-b99785f5194a",
  "timestamp": "2026-07-13T02:15:00Z",
  "evaluationResultId": "e5f6a7b8-c9d0-1234-5678-90abcdef1234",
  "monitoringRuleId": "9a8b7c6d-5e4f-3210-fedc-ba9876543210",
  "ruleName": "Turnover decline > 20%",
  "runDate": "2026-07-13",
  "interpretation": [
    "Turnover over the last 12 months is down 24% versus the prior year."
  ],
  "recommendedAction": [
    "Review the customer's facility limit before the next drawdown."
  ]
}

Prerequisites​

Next steps​

  • Webhooks - Subscribe, verify signatures, and handle deliveries
  • Reports - Pull insight metrics for a customer on demand
  • Upload banking data - Feed the data that monitoring runs on