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 |
Patterns Work TogetherThese 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.
1. Vendor Webhooks
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.When to Use
- Payment processors send status updates
- Fraud systems push alerts
- External services notify of events
- Real-time notifications required
Benefits
- Immediate notification delivery
- No polling overhead
- Real-time customer updates
- Reduced API call costs
How It Works
1
Webhook Registration
Your connector exposes a secure HTTPS endpoint where the vendor can send notifications. Register this endpoint with the vendor’s system.
2
Receive Notification
Vendor sends HTTP POST request to your webhook endpoint with event payload (payment status, fraud alert, etc.).
3
Validate & Process
Your connector validates the webhook signature, authenticates the request, and processes the payload.
4
Publish to Sync Hub
Transform the vendor payload to your canonical format and publish to Sync Hub for distribution to consuming systems.
Implementation Example
Scenario: Alacriti payment processor sends payment status updates via webhook 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
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
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.When to Use
- Core banking publishes to Kafka
- Payment systems use JMS queues
- Vendor provides message broker access
- High-volume event streams
Benefits
- Scalable event processing
- Replay capabilities
- Decoupled architecture
- Built-in fault tolerance
How It Works
1
Connect to Broker
Your connector establishes connection to the vendor’s message broker (Kafka, JMS, Azure Service Bus, etc.).
2
Subscribe to Topics
Subscribe to relevant topics/queues containing the events your systems need (transactions, account updates, etc.).
3
Consume & Transform
Consume messages from the broker, validate schemas, and transform to your canonical format.
4
Publish to Sync Hub
Publish transformed events to Sync Hub, which distributes to all consuming systems with guaranteed delivery.
Implementation Example
Scenario: Core banking publishes account transaction events to Kafka 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
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
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.When to Use
- Daily transaction batch files
- Account statement generation
- Regulatory reporting files
- Legacy system integrations
Benefits
- Handles large data volumes
- Automated validation
- Error recovery mechanisms
- Audit trail for compliance
How It Works
1
File Arrival
Vendor uploads file to SFTP server, FTP location, or cloud storage (Azure Blob, S3).
2
File Detection
Your file processor connector detects new files using polling, file system events, or cloud notifications.
3
Parse & Validate
Parse file format (CSV, XML, fixed-width, etc.), validate structure, and extract individual records.
4
Event Generation
Create individual events for each record in the file, transform to canonical format.
5
Batch Distribution
Publish events to Sync Hub, which distributes to consuming systems with maintained ordering if required.
Implementation Example
Scenario: Core banking sends daily transaction file via SFTP 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
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
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.When to Use
- Vendors send minimal notifications
- Full data requires API calls
- Additional context needed
- Data aggregation from multiple sources
Benefits
- Reduced notification bandwidth
- Enriched data for consumers
- Consistent data format
- Single point of enrichment
How It Works
1
Receive Notification
Vendor sends lightweight notification with just identifiers (transaction ID, customer ID, etc.).
2
API Enrichment
Your connector makes API calls to vendor or other systems to retrieve complete data.
3
Data Aggregation
Combine data from multiple API calls, add contextual information, apply business rules.
4
Create Complete Event
Transform enriched data to canonical format with all necessary context.
5
Publish to Sync Hub
Publish complete, enriched event to Sync Hub for distribution to consuming systems.
Implementation Example
Scenario: Payment processor sends transaction ID, connector enriches with full payment details 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
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
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.When to Use
- Multiple systems need same data
- Each consumer has different needs
- Avoid point-to-point integration complexity
- Independent consumer scaling
Benefits
- Single publish, multiple deliveries
- Reduced integration complexity
- Independent consumer evolution
- Centralized monitoring
How It Works
1
Single Event Published
Producer connector publishes one event to Sync Hub (transaction, customer update, payment status, etc.).
2
Fan-Out Distribution
Sync Hub automatically distributes the event to all configured consumers simultaneously.
3
Consumer-Specific Processing
Each consumer receives the event and processes it according to their needs—different transformations, filtering, timing.
4
Independent Reliability
Each consumer has its own delivery guarantee, retry logic, and dead letter handling.
Implementation Example
Scenario: Single transaction event distributed to four consuming systems 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
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:Example: Complete Payment Processing Integration
Patterns Used:- File Processing: Daily settlement file with batch transactions
- Webhooks: Real-time payment status notifications
- Event Streaming: Transaction lifecycle events from payment system
- Enrichment: Add customer and account context
- Multi-Consumer: Distribute to all consuming systems
Choosing the Right Pattern
Use this decision tree to select the appropriate integration pattern:1
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
2
Do multiple systems need this data?
- Yes → Add Multi-Consumer Distribution
- No → Direct point-to-point may be sufficient
3
Is data complete in the notification?
- No, need API calls → Add Event Enrichment
- Yes → Proceed with base pattern
4
Are there multiple data sources?
- Yes → Combine multiple patterns (file + webhook + streaming)
- No → Single pattern implementation