# BCP API Overview ## Concept BCP, which stands for **Billing, Collection, and Payment**, is an important module for insurance companies or other entities to manage the financial incoming and expense flows related to insurance transactions. The following diagram depicts important parts of our BCP module: ![Overview](./image/bcp/bcp_overview.png) ### Billing Upon the completion of a transaction within a business module, such as policy issuance or claim settlement, it's necessary to provide data to the BCP module. This data is used not only to record such transactions but also to initiate the process of collecting premiums or paying claims to end-customers. Such a recording process is called **Billing** to have a **Bill** generated. Usually, if the bill is to collect money, it will involve one or multiple ***AR (Account Receivable)*** or if it's to pay out money, it involves one or multiple ***AP (Account Payable)***. One billing can contain multiple ARs or APs and each AR or AP can contain a list of detailed breakdown of ***fees***. From a system implementation perspective, the billing process usually involves integration with multiple systems, including: * Policy Admin * Claim * Reinsurance * Sales Channel * Printing Management All these systems can send their billing information to BCP via our billing APIs for further transactions. Upon receiving the billing, the BCP module can conduct collections, payments, or offsets one by one or consolidate them into multiple statements for bulk operations. ### Collection Once the bill is received, if it's to collect money from customers or other entities, it needs to go through a collection process. Depending on the nature of the collection, there can be multiple scenarios: * Cash Before Cover (Prepayment) Collect premium from the policyholder before policy issuance. This is a separate process due to the extensive integration required for automated policy issuance after prepayment. * Premium Collection and Single Collection This process is usually applicable to customer billing and those personal product lines. It is to collect money and perform offset directly so that AR can be directly collected in one step. Such collection and offset combination allows great transaction convenience. * Suspense Collection This process is usually applicable to agent billing and those commercial product lines. It is to collect money and park it in a temporary account, which is also called a ***Suspense Account***. Later on, the account can be used to offset multiple ARs. Such collection and offset separation allows for greater transaction flexibility. ### Payment/Refund Upon receiving a bill for customer payments or refunds, a payment or refund process is required. * Refund Approval Unlike collecting money, paying out money typically involves extensive approval processes for verification and validation. During the approval process, related finance staff might decide which APs can be paid out and which are in dispute, requiring further investigation before payment. * Payment Confirmation (Single/Massive) Once an AP is approved, electronic bank transfers to customers can take several days to complete. Once such transfer is done, systems need to be updated to show that the payment is settled. ### Offset Offset is a very important process for BCP. It's a process to settle AR/AP and reduce AR/AP balance to 0. Usually, the offset will have two usages: * Application The application process offsets the AR with collected funds. It can be against multiple AR/AP to facilitate a large amount of collection, especially on behalf of channels. * AR and AP Offset AR/AP offset can be used to conduct bulk collection or payment. Then AR/AP under one policyholder/channel or one policy can be offset internally and only the net positive/negative amount needs to go through the collection or payment process. It can only help to clear financial AR/AP entries for those canceled inception policy without payment. * Tolerance Offset and Write-off Tolerance is usually used to offset that tiny amount of money. For example, a policy with a premium amount of 100.01, where the customer is only asked to pay 100, is a common practice for convenience. Write-offs are used to offset bad debts that are deemed uncollectible. ## Key API Behavior ### Persistence and Query Our BCP API focuses on accurately recording and preserving all BCP information. For example, once a collection is performed, we need to capture all information around the piece of collection and load information later on. We provide a BCP query API for searching specific requirements. Especially facilitated by ElasticSearch Engine, the search experience can be excellent even with large amounts of data. ### Status and Balance Change Status changes, particularly in offset-related processes, are another crucial aspect of the BCP API, enabling the achievement of: * AR and AP statuses change between **Outstanding**, **Paid**, and **Cancelled**. * AR and AP balances change from a certain amount of 0. This change can be complex, especially when handling large-scale offsets and reversals. ### BCP Fee and GL Fee Generation In most business scenarios, our BCP is just a middle system, transferring all our financial movement information to a third-party accounting system for financial reconciliation and reporting. Each financial movement resulting from the aforementioned processes is recorded as a separate fee entry, and our BCP backend maintains a detailed list of these entries. Some GL systems might require a single fee entry, while others may require a double fee entry for our single fee. ## Platform API vs iComposer API Unlike policy APIs that focus on atomic CRUD, GIMO BCP APIs incorporate various business aspects, including status transitions, going beyond purely atomic APIs. In other words, all such basic business flows for ARAP/collection/payment/offset/fee process which can be considered as common and multi-tenanted, it’s already incorporated into our BCP core API. However, when we analyze a real business user requirement for BCP in detail, they often extend beyond what our current API offers. Beyond the core transactions outlined in this document, each implementation is likely to require additional features, primarily focused on: 1. Payment Methods - like integration with all kinds of payment gateway 2. Integration – like with PA or claim system 2. Batch Jobs – like premium notice or premium deduction batch 3. Letter - like receipt or reminder letter/email/sms 3. Report – like an operational or reconciliation report 4. Authority - like payment or tolerance authority 5. Upload - like upload collection via Excel All these requirements vary significantly across clients and regions. It’s very hard to make a standard API set reusable for other clients/markets (Of course, something like payment integration still can be built as a common service for specific local markets) and we need a iComposer layer to handle all such issues. Such a iComposer can be based on existing client tech-stacks or the InsureMO native app framework. If users want to learn more about how to develop iComposer leveraging our app framework, they can refer to our InsureMO app framework training series. ## Extendability and Configuration Support One of the strengths of the InsureMO GI API is its flexibility. Supported by the rich configuration capabilities of the InsureMO technical platform, a lot of API behaviors can be adjusted in the following ways: 1. Data model and field configuration for API payload All data objects and fields in the policy API payload can be viewed in the data dictionary. Besides, you can add more dynamic objects and fields to capture more personalized information through the API. 2. Code table and data table configuration for API validation Code table configuration is beneficial not only for generating dropdown lists in UIs but also for validating API payloads to ensure code values align with business logic. 3. Numbering configuration for numbering field in API payload By default, all system-generated numbers, such as collection or payment numbers can be customized through numbering template configuration. 4. Index field configuration for search API Quick and fuzzy search is supported by search engines. By configuring more index fields, you can search for BCP transactions based on various conditions. 5. Message configuration for message body in underwriting and validation API If validation fails, it's important to display relevant messages in the response. All message bodies can be defined in the message configuration in a multi-language way.