An application programming interface lets software request data or actions from another system. Before a bank accepts that request, it needs confidence about which application is calling, what authority it has and whether the message was protected in transit.
Software needs an identity
A calling application presents credentials that distinguish it from other systems. Depending on the design, these may include certificates, cryptographic keys or tokens issued after an approved authentication process.
A credential should identify the application or service using it rather than being shared broadly. Shared, long-lived secrets make it harder to attribute activity and increase the damage that can follow if one connected system is compromised.
Authentication and authorization answer different questions
Authentication establishes which system is making the request. Authorization determines what that authenticated system may do—for example, read a balance, submit a payment instruction or access only a defined customer relationship.
Banks apply least privilege by granting only the permissions needed for the stated purpose. Customer consent, employee authority and business rules may impose additional limits even when the application itself is trusted.
Tokens can narrow access in time and scope
Instead of repeatedly sending a primary credential, an application may receive a time-limited access token describing permitted resources and actions. Expiration, audience restrictions and narrowly defined scopes reduce exposure if the token is intercepted or misused.
The bank validates the token and the request rather than trusting that possession alone proves legitimate intent. Sensitive actions may require stronger proof, a new authorization event or confirmation through another control.
The connection and message also need protection
Encryption protects data while it travels, and certificate validation helps the parties confirm that they reached the intended system. Message signatures, timestamps, unique identifiers and replay controls can provide additional evidence that a request was not altered or reused improperly.
Reliable API design also treats repeated requests carefully. A safe retry should not accidentally create a second payment, account change or other unintended result.
Monitoring closes the control loop
Logs connect the application identity, requested action, decision and outcome. Teams monitor unusual volumes, new locations, failed authentication, excessive permissions and behavior that differs from the connection’s expected purpose.
Credentials must be rotated or revoked when systems, vendors or responsibilities change. Authentication is therefore not a one-time gateway decision; it is part of continuing access governance and incident response.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.