An API is a contract between systems. Changing a field, response, security requirement or processing rule can improve the service, but an unmanaged change can also interrupt every application that depends on the old behavior.
The bank first maps who depends on the contract
An inventory connects each API to its owner, purpose, data, authentication method, internal consumers, external clients and critical business services. Logs and gateway data help identify actual use that documentation may have missed.
The impact includes indirect dependencies. A mobile feature may call an internal service that relies on a provider API, so the customer-facing team may not know that a provider's change can affect its journey.
Changes are classified before implementation
Adding an optional field is usually different from removing a field, changing its meaning or requiring a new authentication flow. Teams identify whether the change is backward compatible, security driven, operationally urgent or likely to alter a financial result.
Versioning keeps incompatible contracts distinct rather than silently changing the existing one. The approach should cover message schemas, error codes, limits and business rules—not only the URL label.
A deprecation window gives consumers time to move
The owner communicates the new version, migration steps, test environment, support contacts and date when the old version will stop. Critical clients are tracked individually rather than assuming that a general announcement was received and understood.
The window reflects risk and complexity. A severe vulnerability may require faster action, while a high-volume payment integration can require parallel operation and formal readiness evidence before retirement.
Testing covers behavior, security and financial records
Contract tests confirm expected fields and responses, while end-to-end tests follow representative customer and transaction journeys. Negative tests cover invalid requests, duplicate submissions, timeouts, rate limits and authorization failures.
For account-changing activity, the bank verifies idempotency, posting, reconciliation and audit records. A technically successful response is not enough if the downstream balance or payment status is wrong.
Controlled rollout and retirement close the change
Traffic may shift gradually to the new version with monitoring for errors, latency, complaints and reconciliation differences. A tested rollback or containment path remains available while exposure expands.
The old version is removed only after approved consumers have migrated or received a governed exception. Credentials, documentation, alerts and unused code are then retired so a supposedly closed interface does not remain an unmonitored path.
Read the primary material
Banking Explained prioritizes regulators, official publications and first-party announcements.