One payment service, several insurance businesses. What should stay different?
Matías Bonvin· Updated
An insurance group wants to reuse an AI-enabled payment workflow across business lines. The technical components look familiar: identify the recipient, prepare an instruction, obtain approval, send it and reconcile the response.
The business meaning varies. A claims payment, a premium refund and a reinsurance settlement can depend on different evidence, authority and accounting treatment. Giving them the same screen does not settle those differences.
The useful design question is where reuse ends and domain-specific decisions begin.
Compare two real workflows before building the common one
Choose two payment types and follow them from the business decision to reconciliation. Record who establishes the amount, which event makes it payable and what evidence authorises release.
Then compare the handling of a rejected payment, changed bank details and a partial settlement. These cases often reveal distinctions that a successful demonstration hides.
For example, “payment failed” may mean the instruction was rejected before execution, or it may mean its outcome is not yet known. The next action is different. Retrying an uncertain instruction without checking its status can create a duplicate.
An assistant can prepare the comparison from documented procedures and representative records. Domain owners need to confirm the meaning of each state. A shared label is not sufficient evidence that the states are equivalent.
Reuse the mechanisms that are genuinely common
Identity controls, access management, secure transport, status retrieval and audit records may support several workflows. Their precise configuration still needs to fit the relevant data and operating requirements.
A common service can expose a defined interface while each business line supplies its authorised instruction. This can reduce duplicated plumbing without forcing every line into the same decision process.
Keep the boundary explicit. Which fields does the common service validate? Which decisions must already have been made? Who owns reconciliation if an external response is delayed? What information returns to the source system?
These questions are more revealing than a product slide showing connected boxes.
Preserve the business meaning around the action
The source workflow should retain the reason for payment, the relevant contract or claim, the approved amount and the authority used. The shared service should not have to infer that meaning from a free-text description.
An AI assistant may help assemble or check the instruction. It should use the applicable rules for that payment type and stop when required evidence is absent. A rule valid for a premium refund cannot be assumed valid for a negotiated reinsurance settlement.
Keep sensitive data limited to what each component needs. A technical ability to connect systems does not grant unrestricted access across the group.
Test the return path as carefully as the request
A payment request can be technically accepted while the business record remains wrong. Test how completion, rejection and uncertainty return to the originating workflow.
| External result | Business question |
|---|---|
| Instruction accepted | Has money moved, or only the request entered processing? |
| Payment rejected | Who resolves the cause and authorises the next attempt? |
| Response unavailable | How is status checked before any retry? |
| Payment completed | Which ledger and case records must be reconciled? |
The answers may differ by payment type. Preserve those differences in the integration contract and test cases.
An assistant that writes a confident customer message from the wrong status can create a new service problem even when the payment interface itself worked correctly.
Ask suppliers to demonstrate the boundary
If a vendor proposes one platform for everything, ask it to execute the two selected workflows, including failures and recovery. If another proposes connecting existing systems, ask for the same evidence.
Compare what can be configured, what requires custom work and what remains the client's responsibility. Include the practical cost of maintaining mappings and business rules as the products change.
There is no need to decide the architecture from a slogan about unification. The demonstration should show whether the design preserves the decisions your businesses must make while reducing avoidable duplication.
Bring two workflows that appear suitable for reuse to a Strategy Session. We can compare their common mechanisms and the domain boundaries that a shared service needs to respect.