For Cognitive Payment Hub (CPH)

Patterns Sherlock Cognitive Payment Hub (CPH) can receive Swift Messages, Domestic Proprietary Payment Messages, Bulk Files, E-Mail Messages, JSON Messages, XML Messages, Text Files from Registered Participants and process the same by applying the Standard Operating Procedure (SOP). With an optional acknowledgement of receipt to the sending Participant, CPH can process the request further through the flow.

The generated response again, can be in SWIFT, Domestic Proprietary Payment Messages, Bulk Files, E-Mails, JSON Messages, XML Messages, Text Files.


  • All incoming request messages / files from Registered Participants and Systems are auto-classified and based on the classification the SOP to be used area mapped
  • These incoming messages can be Screened, Validated and Spam Filtered
  • Message / files are processed as per the SOP
  • Response message(s) are generated
  • Response Messages are dispatched to the Recipient / Participant
  • System is enabled to provide Statistics, Accounting and Billing
  • System can maintain a searchable database of messages
  • SOPs are to be defined, maintained and versioned by Operations Team
  • SOP change does not require Change / Addition of Code
  • System can Track and Mark-Off Acknowledgements & Confirmation Messages received from Receiving Participants
  • System can send Acknowledgements and Forward Confirmations received to sending Participants and Systems
  • System has the capabilities to execute completely Independent Process Threads running for Messages and Bulk File Processing
  • System composed of Process Threads & all these Process Threads can be executed on Docker Containers and Kubernetes can be used for container orchestration
  • Process Threads can Scale Up and Down automatically based on the load
  • Process Threads can be executed on Server Class Systems or on a farm of Commodity Servers managed by Process Manager Thread
    Console Manager instances can be used to monitor and control the Threads

Security in Operations

  • System can implement Message Level Security including Encryption and Digital Signatures
  • System implements Security and Isolation for each Process Thread
  • System can provide differentiated Security Provisions based on Message Class or Financial Thresholds

Accounting Provisions

  • System provides Batched and Consolidated Settlements for Messages or Real-Time Settlement for each Message
  • Choice of Batches and Individual Settlements can be configured based on Message Classification / Message Product / Message Value
  • System can integrate with Settlement Systems or Accounting Systems for Accounting Settlements


  • Capable of executing thousands of Process Threads to provide huge processing scale
  • Designed to ensure no bottlenecks in System Architecture including Database Elements
  • Larger Participants (with higher message loads) can be provided with multiple incoming, outgoing and dedicated process threads
  • Capable of understanding Daily Peaks, Periodical Peaks, Participant Load Behavior and prepare Process Thread Mix as per the knowledge of Message Mix and Message Loads
  • Designed the Expensive Process Units to have a high-level Run-time Re-use to ensure huge capacity / scale for message processing
  • Message Storage in Database uses encryption to store Original Copy of a Message and Database elements that provide instant search of a message use non-encrypted storage