Wych events provide a consistent way to record, publish, and consume platform activity across Wych services.

Events are used for operational monitoring, audit trails, reporting, troubleshooting, support workflows, compliance evidence, and downstream integrations such as event hubs, logging platforms, customer notification systems, and reporting services.

The Wych Events schema represents an array of event objects. Each item in the array is a flat event structure that describes a single activity or system occurrence.

Event payload structure​

The root payload is an array. Each item in the array represents one Wych event.

{[
  {
    "id": "2f2a9e3c-2c5d-4b76-b62f-58c6a4a93f20",
    "timestamp": "2026-05-21T01:12:45Z",
    "eventType": "OB_CONSENT_GRANTED"
  }
]}

Required fields​

Each event must include the following fields.

Optional fields​

Events may also include additional context fields.

The schema allows additional properties so that services can include extra event-specific metadata where required. Consumers should not depend on undocumented fields unless agreed as part of an integration contract.

Event type groups​

Event types are grouped by the platform area or workflow they relate to.

Third-party provider events​

These events relate to third-party provider onboarding, access requests, documentation, and key management.

Open banking events​

These events relate to open banking consent, data access, and payment initiation journeys.

Partner portal events​

These events relate to activity performed through the Wych partner portal.

Consent portal events​

These events relate to consent portal activity, support interactions, data extracts, token refreshes, and consent failures.

Gateway API events​

Gateway API events relate to requests handled by Wych gateway services. These are typically useful for request tracing, operational auditing, and integration troubleshooting.

API events​

API events relate to service-level API processing.

Authentication events​

Authentication events relate to login, registration, token exchange, and identity platform activity.

Compliance testing events​

Compliance testing events relate to the lifecycle of a compliance test, certification test, conformance run, or validation workflow.

Example event payload​

The following example shows a batch of Wych events.

{[
  {
    "id": "2f2a9e3c-2c5d-4b76-b62f-58c6a4a93f20",
    "timestamp": "2026-05-21T01:12:45Z",
    "eventType": "OB_CONSENT_GRANTED",
    "tenant": "example-bank",
    "client": "example-client",
    "session": "session-123",
    "message": "Customer granted consent for account and transaction data.",
    "initiator": "user-456",
    "traceId": "00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-00",
    "apiId": "consent-service",
    "httpMethod": "POST",
    "url": "/consents",
    "responseCode": 201,
    "idempotencyKey": "consent-request-789"
  },
  {
    "id": "a79b94c9-6a18-4c0d-9d5c-8d30ef87f1f4",
    "timestamp": "2026-05-21T01:13:02Z",
    "eventType": "API_RESPONSE_SENT",
    "tenant": "example-bank",
    "client": "example-client",
    "message": "Account detail response returned successfully.",
    "traceId": "00-4bf92f3577b34da6a3ce929d0e0e4736-9f3c8a27b5e42d61-00",
    "apiId": "accounts-api",
    "httpMethod": "GET",
    "url": "/banking/accounts/account-123",
    "responseCode": 200
  }
]}

Handling sensitive information​

Event payloads must not contain sensitive customer data, access tokens, refresh tokens, authorisation codes, secrets, private keys, or unredacted credentials.

URLs must be scrubbed of sensitive query parameters before they are included in an event.

The message field should provide enough context to support operational investigation, but it should not be used as a general-purpose data container.

Using events​

Consumers should use eventType as the primary discriminator for routing and filtering.

Where more detailed correlation is required, consumers should use supporting fields such as traceId, tenant, client, session, apiId, and idempotencyKey.

Events can be used to:

• monitor platform activity;
• support operational troubleshooting;
• correlate requests across distributed services;
• support customer and partner reporting;
• provide audit evidence;
• trigger downstream notifications or workflows;
• support security and compliance investigations.

Consumer guidance​

Consumers should treat each item in the event array as an independent event.

A payload may contain one event or multiple events. Consumers should process each event separately and should not assume that all events in a batch relate to the same tenant, client, session, API, or trace.

Consumers should also allow for additional fields, as the schema permits additional properties for service-specific metadata.