Real-Time Firm Banking
What is Firm Banking?
Imagine needing to pay salaries to thousands of employees on payday every month. It is not realistic for a person to log into internet banking and process each transaction one by one. The same applies to settling payments with partners or processing customer refunds. As the volume of financial operations grows, manually handling each transaction hits a hard limit.
Firm Banking is a service that directly connects a company's internal systems to banks for automated financial transaction processing. By integrating through Hecto Financial, you can connect to multiple banks — such as Kookmin, Shinhan, and Woori — all at once, eliminating the need to sign separate contracts and develop individual systems for each bank.
Ideal for These Use Cases
- Automated Payroll : Automatically processes bulk transfers to thousands of employee accounts on payday.
- Partner Settlement : The system directly handles periodic payments to partners and affiliates.
- Subscription Billing : Automatically debits monthly fees, insurance premiums, etc. from customer accounts.
- Refund Automation : Instantly transfers funds to customer accounts when an order is cancelled or a refund is requested.
- Real-Time Deposit Notification : Instantly notifies internal systems when a deposit is made to the corporate account.
Supported Features
Both KRW and foreign currency are supported, providing all the functions needed for corporate fund operations — from transfers to inquiry and notification.
| Feature | Description | KRW | Foreign Currency |
|---|---|---|---|
| Payment Transfer | Real-time transfer to same-bank/other-bank accounts. Used for payroll disbursement, partner settlement, etc. | O | O |
| Collection Transfer | Automatic debit from same-bank accounts. Used for subscription services, recurring billing, etc. | O | O |
| Account Holder Name Lookup | Verifies the account holder name of the recipient before a transfer. Prevents transfer errors in advance. | O | O |
| Balance Inquiry | Queries the current balance of the corporate account. | O | O |
| Transfer Result Inquiry | Checks the result of a processed transfer transaction. Must be used in the event of a timeout. | O | O |
| Transaction Notification | Instantly notifies the corporate system when a deposit or withdrawal occurs on the corporate account. | O | O |
| Exchange Rate Inquiry | Queries the current exchange rate information before a foreign currency transfer. | X | O |
Virtual Account VAVS
If you need to integrate bank messages directly for virtual-account deposits, cancellations, recipient inquiries, and remittances, use the separate VAN Virtual Account (VAVS) service. It uses the same fixed-length TCP/IP method as KRW firm banking, but with a different common header and transaction-code system.
VAN Virtual Account is a separate service
Understanding the Service
A firm banking transaction originates from the corporate system, passes through the financial network (VAN), and is delivered to the bank's internal systems. The entire process is typically completed within a few seconds, as illustrated in the flow diagram below.
Payment Transfer Flow
Transaction Notification Flow
Transfer Result Inquiry Required
For a more detailed look at what happens at each step, see Firm Banking Transaction Flow Structure.
Communication Protocol
Firm banking uses TCP/IP socket communication rather than standard HTTP REST APIs. Because messages are sent and received continuously while maintaining a socket connection, it is well-suited for high-volume processing, but requires developing a separate socket client program.
| Item | KRW | Foreign Currency |
|---|---|---|
| Protocol | TCP/IP Socket | TCP/IP Socket |
| Message Size | Common Header 100B + Individual Body 200B = 300B | Common Header 100B + Individual Body 1900B = 2000B |
| Actual Send/Receive Size | Length Header 4B + Message 300B = 304B | Length Header 4B + Message 2000B = 2004B |
| Encoding | EUC-KR | EUC-KR |
| Connection Mode | Synchronous (request-response) / Asynchronous (session keep-alive) | Synchronous (request-response) / Asynchronous (session keep-alive) |
Message Structure
A message is an agreed-upon data format that bank systems and corporate systems can mutually understand. Every message consists of two sections — the Common Header and the Individual Body — and all transactions including transfers, inquiries, and notifications are processed based on this structure.
Message Number Unique Key
A detailed breakdown of the actual field layout and sample data is also available. Understanding the Firm Banking Message Structure
Key Features and Characteristics
Now that you understand the message structure, let's look at how each feature actually works.
| Feature | Description | Notes |
|---|---|---|
| Payment Transfer | Real-time transfer to same-bank/other-bank accounts. Used for automated payroll, partner settlement, and customer refund processing. | Processing order: Account Holder Name Lookup (6000/100) → Transfer Request (2000/100) |
| Collection Transfer | Automatic debit from a customer's same-bank account. Used for subscription recurring billing, monthly auto-payment, insurance premium collection, etc. | Must register the customer account in advance via Debit Account Registration (2000/550) |
| Transaction Notification | Instantly notifies the corporate system when a deposit or withdrawal occurs on the corporate account. Used for real-time deposit confirmation, bank transfer confirmation, etc. | If a notification is missed, use the missing notification sequence to re-receive it (4000/200) |
| Asynchronous Session Keep-Alive | Allows continuous sending and receiving of messages while maintaining the connection. | Must send a polling message every 5 minutes to maintain the session |
Important Notes
| Item | Details |
|---|---|
| Session Open Message Required | The session open message (1000/100) must be sent before the start of business every day. If not sent, transfer messages for that day will not be processed. |
| No Retry on Timeout | Even if a timeout occurs, the bank may have already processed the transaction successfully. Always verify the transaction status via the Transfer Result Inquiry (7000/100) before deciding whether to reprocess. |
| Duplicate Transfer Prevention | Use a unique message number for each transfer request and always check the transaction status before retrying. Retrying without verification can lead to duplicate transfer incidents. |
| Inter-Bank Transfer Failure Handling | When using the inter-bank transfer failure notification (3000/100), a failure notification may be received after the transfer response code indicates success. This must be reflected in the final result. |
| Strict Message Format | Since fixed-length messages are used, field length, position, and encoding must be exact. Any format mismatch will cause the bank system to return an error code. |
| Service Application Required | Real-time firm banking requires a separate contract and bank review. Please contact your sales representative. () |
Real-Time Firm Banking Developer Documentation
Need technical support?
Code Samples
HectoFinancial GitHub