Chapter 2: Exchange Protocols & Communication

The Protocol Landscape

Financial data exchange operates across a spectrum of protocols, each optimized for specific use cases. Understanding when to use each protocol is critical for building efficient, scalable systems. This chapter explores the major protocols supported by WIA-FIN-021.

RESTful APIs & HTTP/2

REST (Representational State Transfer) has become the de facto standard for web APIs, including financial services. Its simplicity, statelessness, and use of standard HTTP methods make it accessible and easy to implement.

Core REST Principles

Resource-Based: Everything is a resource (accounts, transactions, payments)
HTTP Methods: GET for retrieval, POST for creation, PUT/PATCH for updates, DELETE for removal
Stateless: Each request contains all necessary information
Cacheable: Responses can be cached to improve performance
Uniform Interface: Consistent patterns across all endpoints

                // Retrieve account information
GET /api/v1/accounts/ACC-12345
Authorization: Bearer eyJhbGciOiJSUzI1NiIs...
Accept: application/json

Response 200 OK:
{
  "accountId": "ACC-12345",
  "customerId": "CUST-67890",
  "accountType": "CHECKING",
  "currency": "USD",
  "balance": {
    "available": 2350.00,
    "current": 2500.00,
    "pending": 150.00
  },
  "status": "ACTIVE"
}
            

HTTP/2 Advantages

HTTP/2 brings significant performance improvements for financial APIs:

Multiplexing: Multiple requests over a single connection
Header Compression: Reduced overhead for repeated headers
Server Push: Proactively send related resources
Binary Protocol: More efficient than text-based HTTP/1.1

Use Case	Why REST?
Account Information	Simple, cacheable, standard format
Payment Initiation	Clear request/response, idempotency support
Customer Onboarding	CRUD operations, document uploads
Reporting	Pagination, filtering, sorting support

GraphQL for Financial Data

GraphQL offers a more flexible alternative to REST, allowing clients to request exactly the data they need. This is particularly valuable in financial services where different applications need different views of the same underlying data.

Key Advantages

Precise Data Fetching: Request only needed fields
Single Request: Retrieve related data in one query
Strongly Typed: Schema defines exact data structure
Real-time Updates: Built-in subscription support

                // GraphQL query for customer portfolio
query GetPortfolio($customerId: ID!) {
  customer(id: $customerId) {
    id
    name
    accounts {
      id
      type
      balance {
        available
        currency
      }
      transactions(last: 10) {
        id
        amount
        description
        date
      }
    }
    investments {
      positions {
        symbol
        quantity
        currentValue
      }
    }
  }
}
            

When to Use GraphQL

Complex data models with many relationships
Multiple client types (mobile, web, internal)
Need to aggregate data from multiple sources
Bandwidth optimization is critical (mobile apps)

gRPC & High-Performance RPC

gRPC is Google's Remote Procedure Call framework, designed for high-performance, low-latency communication. It's increasingly used in financial services for internal microservices and high-frequency trading systems.

gRPC Characteristics

Protocol Buffers: Efficient binary serialization
HTTP/2 Based: Multiplexing, streaming, flow control
Code Generation: Automatic client/server code from schema
Streaming: Unary, server streaming, client streaming, bidirectional

                // Protocol Buffer definition
syntax = "proto3";

service MarketDataService {
  rpc GetQuote(QuoteRequest) returns (Quote);
  rpc StreamQuotes(StreamRequest) returns (stream Quote);
}

message QuoteRequest {
  string symbol = 1;
}

message Quote {
  string symbol = 1;
  double last_price = 2;
  int64 volume = 3;
  double bid = 4;
  double ask = 5;
  int64 timestamp = 6;
}
            

Performance Comparison

Metric	REST/JSON	gRPC/Protobuf	Improvement
Serialization Time	2.5ms	0.3ms	8.3x faster
Payload Size	1,200 bytes	250 bytes	4.8x smaller
Latency (p95)	45ms	8ms	5.6x faster

Real-time Streaming

WebSocket for Bidirectional Communication

WebSocket provides full-duplex communication over a single TCP connection, ideal for real-time financial data like market quotes, price updates, and notifications.

                // WebSocket client for market data
const ws = new WebSocket('wss://api.exchange.com/v1/marketdata');

ws.on('open', () => {
  // Subscribe to symbols
  ws.send(JSON.stringify({
    type: 'subscribe',
    symbols: ['AAPL', 'GOOGL', 'MSFT']
  }));
});

ws.on('message', (data) => {
  const quote = JSON.parse(data);
  console.log(`${quote.symbol}: $${quote.price}`);
  updateUI(quote);
});

ws.on('error', (error) => {
  console.error('WebSocket error:', error);
  reconnect();
});
            

Server-Sent Events (SSE)

SSE provides a simpler alternative to WebSocket when you only need server-to-client streaming. It works over standard HTTP and automatically handles reconnection.

                // Server-Sent Events for transaction notifications
const eventSource = new EventSource('/api/v1/transactions/stream');

eventSource.addEventListener('transaction', (event) => {
  const transaction = JSON.parse(event.data);
  if (transaction.amount > 1000) {
    showNotification(`Large transaction: $${transaction.amount}`);
  }
});

eventSource.onerror = (error) => {
  console.error('SSE error:', error);
  // Browser automatically reconnects
};
            

MQTT for IoT & Edge Devices

MQTT (Message Queuing Telemetry Transport) is a lightweight pub/sub protocol ideal for constrained environments like ATMs, point-of-sale terminals, and mobile devices.

Minimal Overhead: Fixed 2-byte header
Quality of Service: At-most-once, at-least-once, exactly-once delivery
Last Will: Automatic notification if client disconnects
Retained Messages: New subscribers get last message immediately

Message Queues & Event Streaming

Apache Kafka

Kafka is the dominant platform for event streaming in financial services, handling trillions of messages per day at major institutions.

High Throughput: Millions of messages per second
Durability: Replicated, persistent storage
Scalability: Horizontal scaling across clusters
Replay: Reprocess historical events

                // Kafka producer for transaction events
const producer = kafka.producer();

await producer.send({
  topic: 'financial.transactions',
  messages: [
    {
      key: transaction.accountId,
      value: JSON.stringify({
        transactionId: transaction.id,
        accountId: transaction.accountId,
        amount: transaction.amount,
        type: transaction.type,
        timestamp: Date.now()
      }),
      headers: {
        'event-type': 'TRANSACTION_CREATED',
        'source-system': 'core-banking'
      }
    }
  ]
});
            

RabbitMQ

RabbitMQ excels at complex routing scenarios and provides strong delivery guarantees for critical financial messages.

Flexible Routing: Direct, topic, fanout, headers exchanges
Message Priority: High-priority messages jump the queue
Dead Letter Queues: Handle failed messages gracefully
Plugin Ecosystem: Extend with custom functionality

Protocol Selection Guide

Use REST When:

Simple CRUD operations
Caching is important
Wide client compatibility needed
Human-readable debugging preferred

Use GraphQL When:

Complex data relationships
Multiple client types
Bandwidth optimization critical
Rapid iteration needed

Use gRPC When:

Low latency required
Microservices communication
Bidirectional streaming
Strong typing needed

Use WebSocket When:

Real-time updates
Bidirectional needed
Low latency critical
Browser compatibility required

                Best Practice: Most financial systems use multiple protocols. REST for
                public APIs, gRPC for internal microservices, Kafka for event streaming, and WebSocket
                for real-time client updates. Choose the right tool for each job.
            

Protocol Security Considerations

Regardless of which protocol you choose, security must be built in from the start:

Transport Security: Always use TLS 1.3 for all protocols
Authentication: OAuth 2.0, JWT, or mutual TLS
Rate Limiting: Protect against abuse and DDoS
Input Validation: Validate all data at protocol boundaries
Monitoring: Log and monitor all protocol interactions

In the next chapter, we'll explore data formats and how to structure the information flowing through these protocols.