SIC Instant Payment APIs
ImPAI API Architecture Overview​
ImPAI provides a comprehensive set of RESTful APIs that support the full lifecycle of SIC Inst (Swiss Interbank Clearing Instant) payments — handling initiation and validation as well as processing R-Transactions.
These services are structured to provide:
- ✅ Modular and scalable integration
- ✅ End-to-end traceability across payment message flows
- ✅ Consistent data models and validation rules
- ✅ Seamless interoperability with core banking, clearing systems, and monitoring layers
Service Categories​
| Category | Purpose |
|---|---|
| Initiation Services | Create, update, or cancel payment instructions before processing. |
| R-Transaction Services | Handle recall, return, and resolution exception flows. |
| Validation Services | Perform data integrity and SEPA rule validation at multiple stages. |
Each service category defines consistent API endpoints and follows standardized message formats to ensure reliable integration with external and internal systems.
Where Each API Fits in the SIC Inst Lifecycle​
SIC Inst processing involves several coordinated steps, and each API in ImPAI is designed to support a specific part of this lifecycle. The diagram below provides a high-level overview of where each service fits — from the initial payment initiation through validation, settlement, inquiries, and exception handling. Use it as a guide to understand how the different API categories interact within the full processing journey.
| Legend | |
| Underlined Blue | Clickable — opens the corresponding API documentation section |
| Light Blue | Processing step without API support yet |
| Light Green | Core execution stage that interacts with clearing & settlement systems |
Supported Message Types​
ImPAI supports the following Instant Payment message types required by the SIC IP Rulebook.
Messages are exchanged using ISO 20022 formats and extended internally with additional metadata for processing and traceability.
| Message Type | Full ISO Name | Purpose in SIC Inst |
|---|---|---|
| pacs.002.001.10.ch.02 | FI Payment Status Report | Status feedback between banks or from clearing system. |
| pacs.004.001.09.ch.02 | Payment Return | Return of funds when a credit transfer cannot be completed. |
| pacs.008.001.08.ch.02 | Financial Institution Credit Transfer | Credit transfer between banks via the clearing system. |
| pacs.028.001.03.ch.01 | FI Payment Status Request (Inquiry) | Request for payment status or investigation case. |
| camt.025.001.05.ch.02 | Receipt | Application-level receipt / acknowledgement that a message was received. |
| camt.029.001.09.ch.03 | Resolution of Investigation | Response to inquiry or recall — final or interim resolution. |
| camt.056.001.08.ch.04 | FI Payment Cancellation Request (Recall) | Request to cancel a previously sent transaction. |
These message types cover all operational flows:
✅ Standard credit transfers
✅ Exception handling (Recalls, Returns, Inquiries)
✅ Status visibility and between banks
List of Available Endpoints​
| Method | Endpoint | Description | Use Cases |
|---|---|---|---|
| POST | /api/sic-inst/v1/ | Initiates a SIC Instant payment from a PAIN.001. Returns identifier if successfully authorised. | SIC IP Initiation |
| POST | /api/sic-inst/v1/ | Validate the fields in a filled Payment Instruction (pain.001) message. | SIC IP Validation |
| POST | /api/sic-inst/v1/ | Prepares and generates a SIC Instant recall request. Returns a Cancellation ID on success. | SIC IP Recall |
| POST | /api/sic-inst/v1/ | Returns funds for a SIC Instant recall request. Returns Return ID on success. | SIC IP Return of Funds |
| POST | /api/sic-inst/v1/ | Processes a Resolution (negative response) to a SIC Instant recall request. Returns Resolution ID. | SIC IP Recall Resolution |
Message Structure in ImPAI APIs​
ImPAI adopts a unified internal JSON message model to ensure consistent communication across all microservices. This structure standardizes how payments are processed, routed, audited, and monitored throughout the system.
Each message contains the following core components:
| Component | Description |
|---|---|
| Common Metadata | Identifiers, timestamps, system of origin, message type, and lifecycle context. Enables full traceability and audit compliance. |
| Routing Information | Internal addressing details such as processing queues, target services, and flow control indicators. |
| Processing State | Current execution status including intermediate stages, retry counters, timestamps, and error diagnostics. |
| Data Payload | The business transaction content based on ISO 20022 message structures (e.g., pacs.008, camt.056), enriched with internal fields where required. |
Although the external API uses standardized request/response models, ImPAI converts them into this internal normalized format to maintain stability and extensibility across services.