Authentication and Authorization

Initiation Phase

Card 17 explained validation at initiation. Validation checks whether the payment data is acceptable enough to continue. Card 18 explains authentication and authorization, which answer two different but closely connected questions. Authentication asks, “Who is this person or system?” Authorization asks, “Is this authenticated person or system allowed to perform this action on this payment?” Consent sits inside the same control area because a payment should not move forward merely because the data is valid. The right customer, user or authorized representative must approve the instruction in a way the bank can evidence.

This distinction is essential in real banking. A payment can pass all data checks and still be unsafe if the wrong person approved it. Malla may enter correct beneficiary, amount and date, but if someone else used his credentials, the payment is not properly authorized. Guna Manufacturing may upload a perfect supplier file, but if Gunaditya is allowed only to create files and not release them, the payment cannot be treated as fully authorized. Sravanthi may approve a transfer, but if the amount is above her delegated authority, another approval may be required. Ramesh may be a view-only user in a corporate portal, so even if he can see payment data, he cannot approve movement of funds.

Authentication and authorization are not just login screens. They are lifecycle controls. They influence whether the bank accepts the instruction, whether further approval is required, whether fraud checks are strengthened, whether customer notifications are triggered, whether audit records are created, whether the payment can be released to processing, and whether the bank can defend the payment later if a dispute arises. Weak authorization creates direct financial risk because payment systems move real value based on trusted instructions.

In modern payment environments, authorization is often layered. A customer may authenticate at login, again at payment confirmation, and again when approving a risky or high-value transfer. A corporate user may create a payment but not release it. A second user may approve it. A third user may be required above a threshold. An API client may authenticate using certificates or tokens, but the underlying corporate mandate still determines what it may submit. A file may be received from a secure host-to-host channel but still need human approval in the bank portal. The control design must be clear about what each layer proves.

Explore the complete Payment Life Cycle