> ## Documentation Index
> Fetch the complete documentation index at: https://grandcentral.backbase.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Sync Hub integration patterns

> Five core integration patterns for real-time data synchronization and event distribution

Sync Hub supports five fundamental integration patterns that address the most common banking data synchronization scenarios. Each pattern solves specific challenges in connecting banking systems, vendors, and channels.

## Pattern selection guide

Choose the right pattern based on how your source system delivers data:

| Source system delivers...        | Integration pattern | Use when                                                                   |
| -------------------------------- | ------------------- | -------------------------------------------------------------------------- |
| **Inbound API calls (webhooks)** | Vendor webhooks     | Payment processors, fraud systems, third-party services send notifications |
| **Messages to a broker**         | Event streaming     | Core banking, payment systems publish to Kafka, JMS, or similar            |
| **Files via SFTP/FTP**           | File processing     | Batch transaction files, statements, or regulatory reports                 |
| **Minimal notifications**        | Event enrichment    | Systems send IDs only, requiring API calls for full data                   |
| **Events for multiple systems**  | Multi-consumer      | One event must reach digital channels, CRM, analytics, and more            |

<Info>
  **Patterns work together**

  These patterns complement each other. A single integration might use file processing for batch data, webhooks for real-time updates, and multi-consumer distribution to reach all downstream systems.
</Info>

## 1. Vendor webhooks

Receive real-time notifications from external services through secure HTTP endpoints.

### Pattern overview

Payment vendors, fraud detection systems, and third-party services often require your system to expose HTTP endpoints (webhooks) where they can push real-time notifications.

<CardGroup cols={2}>
  <Card title="When to use" icon="circle-check">
    * Payment processors send status updates
    * Fraud systems push alerts
    * External services notify of events
    * Real-time notifications required
  </Card>

  <Card title="Benefits" icon="star">
    * Immediate notification delivery
    * No polling overhead
    * Real-time customer updates
    * Reduced API call costs
  </Card>
</CardGroup>

### How it works

<Steps>
  <Step title="Webhook registration">
    Your connector exposes a secure HTTPS endpoint where the vendor can send notifications. Register this endpoint with the vendor's system.
  </Step>

  <Step title="Receive notification">
    Vendor sends HTTP POST request to your webhook endpoint with event payload (payment status, fraud alert, etc.).
  </Step>

  <Step title="Validate and process">
    Your connector validates the webhook signature, authenticates the request, and processes the payload.
  </Step>

  <Step title="Publish to Sync Hub">
    Transform the vendor payload to your canonical format and publish to Sync Hub for distribution to consuming systems.
  </Step>
</Steps>

### Implementation example

**Scenario:** Alacriti payment processor sends payment status updates via webhook

```mermaid theme={"system"}
%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryBorderColor': '#295eff',
    'primaryTextColor': '#091c35',
    'lineColor': '#091c35',
    'secondaryColor': '#f3f6f9',
    'tertiaryColor': '#ebf0f5',
    'fontFamily': 'Libre Franklin, sans-serif'
  }
}}%%
graph LR
    A[Alacriti] -->|Webhook POST| B[Your webhook connector]
    B -->|Validate signature| C[Process payload]
    C -->|Transform data| D[Publish to Sync Hub]
    D -->|Distribute| E[Digital banking]
    D -->|Distribute| F[CRM system]
    D -->|Distribute| G[Analytics]
```

**Configuration approach:**

* Build a webhook connector using Grand Central's connector framework
* Implement signature validation for security
* Transform Alacriti's payload to your canonical payment event format
* Configure routing to digital banking, CRM, and analytics systems

### Common use cases

Typical use cases for webhook integration include:

* **Payment status updates** - real-time payment processing status from Alacriti/Volante. Track payment lifecycle from initiated → sent → processed → completed. Includes failed payment notifications with reason codes, settlement confirmations, and chargeback notifications. **Business value:** Immediate customer notification and reduced support inquiries.
* **Fraud detection alerts** - real-time fraud alerts from security vendors. Receive transaction flags for review, account suspension recommendations, suspicious activity pattern detection, and velocity threshold breaches. **Business value:** Immediate fraud prevention and reduced losses.
* **Account verification** - third-party KYC/AML verification results. Get identity verification completion, document validation results, risk scoring updates, and compliance status changes. **Business value:** Faster onboarding and automated compliance.

## 2. Event streaming

Consume events from message brokers like Kafka, JMS, or Azure Service Bus.

### Pattern overview

Core banking systems, payment processors, and enterprise applications often publish events to message brokers like Kafka, JMS, or Azure Service Bus. Your connectors consume these events and distribute them through Sync Hub.

<CardGroup cols={2}>
  <Card title="When to use" icon="circle-check">
    * Core banking publishes to Kafka
    * Payment systems use JMS queues
    * Vendor provides message broker access
    * High-volume event streams
  </Card>

  <Card title="Benefits" icon="star">
    * Scalable event processing
    * Replay capabilities
    * Decoupled architecture
    * Built-in fault tolerance
  </Card>
</CardGroup>

### How it works

<Steps>
  <Step title="Connect to broker">
    Your connector establishes connection to the vendor's message broker (Kafka, JMS, Azure Service Bus, etc.).
  </Step>

  <Step title="Subscribe to topics">
    Subscribe to relevant topics/queues containing the events your systems need (transactions, account updates, etc.).
  </Step>

  <Step title="Consume and transform">
    Consume messages from the broker, validate schemas, and transform to your canonical format.
  </Step>

  <Step title="Publish to Sync Hub">
    Publish transformed events to Sync Hub, which distributes to all consuming systems with guaranteed delivery.
  </Step>
</Steps>

### Implementation example

**Scenario:** Core banking publishes account transaction events to Kafka

```mermaid theme={"system"}
%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryBorderColor': '#295eff',
    'primaryTextColor': '#091c35',
    'lineColor': '#091c35',
    'secondaryColor': '#f3f6f9',
    'tertiaryColor': '#ebf0f5',
    'fontFamily': 'Libre Franklin, sans-serif'
  }
}}%%
graph LR
    A[Core banking] -->|Kafka topic| B[Your event consumer]
    B -->|Read messages| C[Transform and validate]
    C -->|Canonical format| D[Publish to Sync Hub]
    D -->|Distribute| E[Digital banking]
    D -->|Distribute| F[Transaction enrichment]
    D -->|Distribute| G[Fraud detection]
```

**Configuration approach:**

* Build an event consumer connector using Grand Central's framework
* Configure Kafka/JMS connection details and authentication
* Implement schema validation for incoming messages
* Transform to canonical transaction event format
* Configure dead letter handling for processing failures

### Common use cases

Typical use cases for event streaming include:

* **Transaction events** - core banking publishes all account transactions to Kafka. Includes deposits and withdrawals, ATM transactions, point-of-sale purchases, wire transfers, and ACH. **Business value:** Real-time transaction visibility across all channels.
* **Account lifecycle events** - account management system publishes state changes. Track account opened, status changed (active, dormant, closed), account holder information updated, and service agreements modified. **Business value:** Consistent account data across all systems.
* **Payment lifecycle events** - payment processing system publishes payment state changes. Follow payment order created, payment approved/rejected, payment sent to processor, and payment completed/failed. **Business value:** Complete payment tracking and audit trail.

## 3. File processing

Process batch files from SFTP, S3, or Azure Blob Storage into event streams.

### Pattern overview

Many banking systems still exchange data via files - batch transaction files, account statements, regulatory reports. Sync Hub processes these files, breaks them into individual events, and distributes to consuming systems.

<CardGroup cols={2}>
  <Card title="When to use" icon="circle-check">
    * Daily transaction batch files
    * Account statement generation
    * Regulatory reporting files
    * Legacy system integrations
  </Card>

  <Card title="Benefits" icon="star">
    * Handles large data volumes
    * Automated validation
    * Error recovery mechanisms
    * Audit trail for compliance
  </Card>
</CardGroup>

### How it works

<Steps>
  <Step title="File arrival">
    Vendor uploads file to SFTP server, FTP location, or cloud storage (Azure Blob, S3).
  </Step>

  <Step title="File detection">
    Your file processor connector detects new files using polling, file system events, or cloud notifications.
  </Step>

  <Step title="Parse and validate">
    Parse file format (CSV, XML, fixed-width, etc.), validate structure, and extract individual records.
  </Step>

  <Step title="Event generation">
    Create individual events for each record in the file, transform to canonical format.
  </Step>

  <Step title="Batch distribution">
    Publish events to Sync Hub, which distributes to consuming systems with maintained ordering if required.
  </Step>
</Steps>

### Implementation example

**Scenario:** Core banking sends daily transaction file via SFTP

```mermaid theme={"system"}
%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryBorderColor': '#295eff',
    'primaryTextColor': '#091c35',
    'lineColor': '#091c35',
    'secondaryColor': '#f3f6f9',
    'tertiaryColor': '#ebf0f5',
    'fontFamily': 'Libre Franklin, sans-serif'
  }
}}%%
graph LR
    A[Core banking] -->|SFTP upload| B[File storage]
    B -->|File detected| C[File processor]
    C -->|Parse CSV| D[Generate events]
    D -->|Canonical format| E[Publish to Sync Hub]
    E -->|Distribute| F[Digital banking]
    E -->|Distribute| G[Analytics]
```

**Configuration approach:**

* Build a file processor connector using Grand Central's framework
* Configure SFTP/FTP connection or cloud storage monitoring
* Implement file format parsing (CSV, XML, fixed-width, etc.)
* Add validation rules for file structure and content
* Configure error handling for malformed files

### Common use cases

Typical use cases for file processing include:

* **Daily transaction files** - core banking sends overnight transaction file containing all transactions for the previous day. Supports batch processing of large volumes with validated and reconciled data, handling multiple transaction types in a single file. **Business value:** Bulk data synchronization with reduced API calls.
* **Account statement generation** - monthly account statements as structured files. Includes account balances, transaction history, interest calculations, and fee assessments. **Business value:** Automated statement delivery to digital channels.
* **Batch payment files** - batch payment instructions from corporate customers. Contains multiple payment orders in file format with validation and approval workflow, processing and status tracking, and results file generation. **Business value:** Efficient bulk payment processing.

## 4. Event enrichment

Enhance events with additional data from APIs, databases, or caches.

### Pattern overview

Some systems send lightweight notifications containing only identifiers to reduce bandwidth. Your connector must make API calls to retrieve full data, enrich it with additional context, then publish complete events.

<CardGroup cols={2}>
  <Card title="When to use" icon="circle-check">
    * Vendors send minimal notifications
    * Full data requires API calls
    * Additional context needed
    * Data aggregation from multiple sources
  </Card>

  <Card title="Benefits" icon="star">
    * Reduced notification bandwidth
    * Enriched data for consumers
    * Consistent data format
    * Single point of enrichment
  </Card>
</CardGroup>

### How it works

<Steps>
  <Step title="Receive notification">
    Vendor sends lightweight notification with just identifiers (transaction ID, customer ID, etc.).
  </Step>

  <Step title="API enrichment">
    Your connector makes API calls to vendor or other systems to retrieve complete data.
  </Step>

  <Step title="Data aggregation">
    Combine data from multiple API calls, add contextual information, apply business rules.
  </Step>

  <Step title="Create complete event">
    Transform enriched data to canonical format with all necessary context.
  </Step>

  <Step title="Publish to Sync Hub">
    Publish complete, enriched event to Sync Hub for distribution to consuming systems.
  </Step>
</Steps>

### Implementation example

**Scenario:** Payment processor sends transaction ID, connector enriches with full payment details

```mermaid theme={"system"}
%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryBorderColor': '#295eff',
    'primaryTextColor': '#091c35',
    'lineColor': '#091c35',
    'secondaryColor': '#f3f6f9',
    'tertiaryColor': '#ebf0f5',
    'fontFamily': 'Libre Franklin, sans-serif'
  }
}}%%
graph LR
    A[Payment processor] -->|Notification| B[Enrichment connector]
    B -->|Get transaction| C[Payment API]
    B -->|Get customer| D[Customer API]
    B -->|Get account| E[Account API]
    C & D & E -->|Aggregate| F[Create complete event]
    F -->|Publish| G[Sync Hub]
```

**Configuration approach:**

* Build enrichment connector using Grand Central's framework
* Configure API endpoints and authentication
* Implement orchestration logic for multiple API calls
* Add caching to reduce API load
* Handle API failures gracefully with retry logic

### Common use cases

Typical use cases for enrichment include:

* **Transaction notifications** - fraud system sends transaction ID for flagged transaction. Enrichment retrieves transaction details from payment system, fetches customer profile and history, gets account information and limits, and adds risk scoring data. **Business value:** Complete context for fraud investigation.
* **Customer update notifications** - vendor sends customer ID for profile update. Enrichment fetches complete customer profile, retrieves account associations, gets preference settings, and adds segmentation data. **Business value:** Full customer view for all consuming systems.
* **Payment status updates** - processor sends payment reference for status change. Enrichment retrieves payment order details, fetches beneficiary information, gets routing and settlement data, and adds fee calculations. **Business value:** Complete payment information for notifications.

## 5. Multi-consumer distribution

Distribute events to multiple consuming systems with independent delivery guarantees.

### Pattern overview

A single data event often needs to reach multiple consuming systems - digital banking channels, CRM, analytics, compliance, and more. Sync Hub's multi-consumer pattern ensures each system receives the event reliably without creating point-to-point integrations.

<CardGroup cols={2}>
  <Card title="When to use" icon="circle-check">
    * Multiple systems need same data
    * Each consumer has different needs
    * Avoid point-to-point integration complexity
    * Independent consumer scaling
  </Card>

  <Card title="Benefits" icon="star">
    * Single publish, multiple deliveries
    * Reduced integration complexity
    * Independent consumer evolution
    * Centralized monitoring
  </Card>
</CardGroup>

### How it works

<Steps>
  <Step title="Single event published">
    Producer connector publishes one event to Sync Hub (transaction, customer update, payment status, etc.).
  </Step>

  <Step title="Fan-out distribution">
    Sync Hub automatically distributes the event to all configured consumers simultaneously.
  </Step>

  <Step title="Consumer-specific processing">
    Each consumer receives the event and processes it according to their needs - different transformations, filtering, timing.
  </Step>

  <Step title="Independent reliability">
    Each consumer has its own delivery guarantee, retry logic, and dead letter handling.
  </Step>
</Steps>

### Implementation example

**Scenario:** Single transaction event distributed to four consuming systems

```mermaid theme={"system"}
%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryBorderColor': '#295eff',
    'primaryTextColor': '#091c35',
    'lineColor': '#091c35',
    'secondaryColor': '#f3f6f9',
    'tertiaryColor': '#ebf0f5',
    'fontFamily': 'Libre Franklin, sans-serif'
  }
}}%%
graph TD
    A[Transaction producer] -->|Publish once| B[Sync Hub]
    B -->|Distribute| C[Digital banking]
    B -->|Distribute| D[CRM system]
    B -->|Distribute| E[Fraud detection]
    B -->|Distribute| F[Analytics platform]
    C -->|Display to customer| C1[Mobile and web]
    D -->|Update history| D1[Customer profile]
    E -->|Risk scoring| E1[Alert generation]
    F -->|Data warehouse| F1[Reporting]
```

**Configuration approach:**

* Producer publishes transaction event once to Sync Hub
* Configure four consumer connectors, each subscribed to transaction events
* Each consumer implements its own transformation logic
* Each consumer has independent retry and error handling
* Monitor each consumer's health separately

### Common use cases

Typical use cases for multi-consumer distribution include:

* **Transaction distribution** - ATM withdrawal event reaches multiple consumers simultaneously. Digital banking displays in transaction history, CRM updates customer interaction timeline, fraud detection analyzes for suspicious patterns, analytics adds to data warehouse for reporting, and compliance maintains audit trail for regulatory reporting. **Business value:** Single event drives comprehensive system updates.
* **Customer profile updates** - customer changes address in branch system. Digital banking updates profile display, CRM updates customer record, marketing updates segmentation data, compliance updates KYC record, and document management updates mailing address. **Business value:** Consistent customer data across all systems.
* **Payment status changes** - payment processor updates payment status. Digital banking sends customer notification, CRM updates payment history, accounting creates journal entry, reconciliation tracks settlement, and reporting captures payment analytics. **Business value:** Complete payment lifecycle tracking.

## Pattern combinations

Real-world integrations often combine multiple patterns for comprehensive data synchronization. The following example shows how patterns work together.

### Example: Complete payment processing integration

```mermaid theme={"system"}
%%{init: {
  'theme': 'base',
  'themeVariables': {
    'primaryColor': '#ffffff',
    'primaryBorderColor': '#295eff',
    'primaryTextColor': '#091c35',
    'lineColor': '#091c35',
    'secondaryColor': '#f3f6f9',
    'tertiaryColor': '#ebf0f5',
    'fontFamily': 'Libre Franklin, sans-serif'
  }
}}%%
graph TB
    A[Payment processor] -->|File processing| B[Batch settlement file]
    A -->|Webhooks| C[Real-time status updates]
    A -->|Event streaming| D[Transaction events]
    B & C & D -->|Enrichment| E[Enrich with customer data]
    E -->|Multi-consumer| F[Sync Hub]
    F --> G[Digital banking]
    F --> H[CRM]
    F --> I[Analytics]
    F --> J[Compliance]
```

**Patterns used:**

1. **File processing:** Daily settlement file with batch transactions
2. **Webhooks:** Real-time payment status notifications
3. **Event streaming:** Transaction lifecycle events from payment system
4. **Enrichment:** Add customer and account context
5. **Multi-consumer:** Distribute to all consuming systems

## Choosing the right pattern

Use this decision tree to select the appropriate integration pattern:

<Steps>
  <Step title="How does the source system deliver data?">
    * **HTTP POST (webhook)** → Use vendor webhooks pattern
    * **Message broker** → Use event streaming pattern
    * **File upload** → Use file processing pattern
    * **Notification with ID** → Use event enrichment pattern
  </Step>

  <Step title="Do multiple systems need this data?">
    * **Yes** → Add multi-consumer distribution
    * **No** → Direct point-to-point may be sufficient
  </Step>

  <Step title="Is data complete in the notification?">
    * **No, need API calls** → Add event enrichment
    * **Yes** → Proceed with base pattern
  </Step>

  <Step title="Are there multiple data sources?">
    * **Yes** → Combine multiple patterns (file + webhook + streaming)
    * **No** → Single pattern implementation
  </Step>
</Steps>

## Next steps

**[Use Cases](/platform/sync-hub-use-cases)** - see real-world examples of these patterns in banking scenarios.

**[Sync Hub Overview](/platform/sync-hub/overview)** - return to Sync Hub overview and architecture.

**[Platform Overview](/platform/overview)** - explore the complete Grand Central platform.