Initiation Fundamentals

Initiation Phase

Card 12 separated movement language into business direction and system direction. Card 13 now moves into the first real phase of the life cycle: initiation. Initiation is where the payment is born, but it is not where the payment is completed. This distinction matters because many payment defects come from treating the first screen, first file, first API call or first customer request as if it were already a fully controlled payment.

In real banks, initiation is not just “the customer entered a payment.” It is the phase in which intention is captured, data is structured, authority starts to be tested, product rules begin to apply, customer promises are shaped, and the bank decides whether there is enough information to receive the instruction into the next layer. A payment that is badly initiated may still look clean on a screen. It may even pass technical validation. But if the customer selected the wrong beneficiary, supplied an old account number, used an unclear purpose, missed a cut-off, chose a wrong currency, uploaded a duplicate file or misunderstood a status message, the downstream life cycle inherits the weakness.

The key discipline in this chapter is simple: initiation should create a payment instruction that is clear enough to control, route, process, account for, report and investigate. If the instruction is vague at birth, every later team pays the price.

The examples use the same learning cast. Malla is the sender in many scenarios. Sravanthi often brings the compliance and control view. Gunaditya brings the correspondent and operations view. Ramesh brings the back-office and receiving-side view. The banks remain Malla Bank, Sravanthi Bank, Guna Bank and Ramesh Bank. The examples are fictional, but the banking logic is real.

Explore the complete Payment Life Cycle