Some ports are called "well-known ports" because they are standardized and reserved

for widely used, common network services. These ports have numbers ranging from 0
to 1023 and are managed by the Internet Assigned Numbers Authority (IANA).

These well-known ports help everyone agree on where specific services can be found so
that communication works smoothly and predictably across the internet.

Why are they important?

●​ Because these ports are fixed for important services, any device or program
knows that, for example, web traffic usually happens on port 80 or 443.
●​ This standardization reduces confusion and ensures compatibility between
different systems.
●​ Port 20, 21: FTP (File Transfer Protocol) for file transfers
●​ Port 22: SSH (Secure Shell) for secure logins
●​ Port 23: Telnet for remote text communication (unencrypted)
●​ Port 25: SMTP for sending emails
●​ Port 53: DNS for domain name resolution
●​ Port 67, 68: DHCP for automatic IP address assignment
●​ Port 80: HTTP for web traffic
●​ Port 110: POP3 for retrieving emails
●​ Port 143: IMAP for managing emails
●​ Port 443: HTTPS for secure web traffic
●​ Port 993, 995: Secure email protocols (IMAPS, POP3S)

SWIFT message transmission typically uses specialized protocols over the SWIFTNet
private network rather than general public internet ports. However, some commonly
referenced port numbers associated with SWIFT message communications include:
●​ Port 257 (TCP/UDP): Often used in SWIFTNet for certain message transports,
such as the SWIFTNet InterAct service which supports FIN messages (financial
messaging).
●​ Other ports may be specific to the SWIFT infrastructure and depend on the exact
SWIFT service and configuration.
Unlike typical internet services, SWIFT operates primarily on a secure, private network
infrastructure with defined communication channels and may not use conventional
public ports like HTTP (80) or HTTPS (443).
Therefore, if dealing with SWIFT message transmission, ports such as 257 are
significant, but exact port usage can vary depending on the SWIFT service and setup.

In general, SWIFT messages themselves are categorized into types (e.g., MT 103, MT
202), but these message types don't dictate specific port numbers; ports relate more to
underlying network transport in SWIFT's secure environment.

API Whitelisting
●​ It’s like having a list of approved visitors who are allowed to use your API.
●​ The API only accepts requests coming from specific IP addresses or users on
this allowed list.
●​ It controls who can connect to your API, enhancing security by blocking everyone
else.
●​ Whitelisting is about restricting access at the application or API level.

Port Opening
●​ This means unlocking a specific network door (port number) on your server or
firewall.
●​ When a port is open, any device can try to connect through that door, but whether
they can use the API depends on additional checks.
●​ Port opening controls whether the door is open or closed to the outside world at
the network level.
●​ It’s a necessary step to make APIs accessible, but alone it doesn’t restrict who
can connect—just that the connection is allowed at the network firewall.
 Feature API Whitelisting Port Opening

Restrict access to API only to trusted

Purpose Allow network traffic on a specific port
IPs/users

Whether network traffic can reach the

Controls Who can use the API
server

Level Application/API layer Network/firewall layer

Security Blocks unauthorized users even if port is

Allows traffic, but doesn’t filter users
Impact open

Apigee is an API management platform developed by Google Cloud, designed to help

organizations build, manage, and secure APIs at any scale or complexity. Here's an
overview of what Apigee offers:
●​ Purpose and Use Cases​
Apigee enables you to create API proxies, which act as intermediaries between
client apps and backend services. This abstraction allows for easier security,
traffic management, transformation, and monitoring of API traffic. It supports a
range of protocols including REST, gRPC, SOAP, and GraphQ
●​ Key Features
○​ Build consistent, high-quality APIs without extensive expertise.
○​ Secure APIs with robust policies and advanced security, including
automated controls to detect misconfigurations and malicious traffic.
○​ Easily create, publish, and govern APIs using a centralized API hub.
○​ Orchestrate and manage traffic for high-demand applications.
○​ Support for hybrid deployment—run containerized runtimes on your own
Kubernetes infrastructure or in the cloud.
○​ Advanced analytics and monitoring tools to track API usage, latency,
errors, and business metrics.
○​ Integrate with developer portals for onboarding, documentation, and
developer engagement.
●​ Developer Productivity​
Developers can quickly build RESTful API proxies, apply policies for enhanced
functionality (security, rate limiting, transformation, caching, etc.), and deploy API
products with specific access controls tailored for different user groups or
business cases.
●​ Security​
Apigee protects APIs through layered security, including authentication,
automated threat detection, bot mitigation, and integration with other Google
Cloud security services like Cloud Armor and reCAPTCHA Enterprise.
●​ History and Ownership​
Apigee was originally founded as Sonoa Systems in 2004, rebranded in 2010,
expanded through acquisitions, and became a founding member of the OpenAPI
Initiative in 2015. Google acquired Apigee for $625 million in 2016, and has since
integrated Apigee into its cloud offerings

●​ Apigee is an API manager. It helps companies open up their services to the

outside world—like letting mobile apps, partners, or other software access your
data in a secure way. It controls who can use your services, keeps things safe,
tracks usage, and offers developer-friendly tools and analytics.
●​ Anthos is a platform for managing applications, especially when they're running
in lots of places (like public cloud, your own data center, or hybrid setup). Anthos
includes a tool called "Service Mesh" that helps apps inside your company talk
securely and reliably, but mainly for internal communication between small app
chunks called microservices.
A service mesh is a specialized infrastructure layer in modern software applications,
especially those built using microservices architecture. Its main job is to manage and
control communication between the multiple small services (microservices) that make
up an application.

How it works:
●​ Each microservice is paired with a lightweight sidecar proxy that intercepts all
incoming and outgoing network traffic for that service.
●​ These proxies handle communication tasks like routing requests, balancing
loads, enforcing security policies (such as encryption and authentication), and
collecting data for monitoring.
●​ The service mesh has two main parts:
○​ Data plane: The collection of sidecar proxies running alongside services,
managing the actual data traffic.
○​ Control plane: The central management system that configures and
manages these proxies, setting rules for traffic, security, and policies.

Why use a service mesh?

●​ It improves how services talk to each other by making communication secure,
reliable, and observable without developers having to add this complexity into
each service.
●​ It automates retry mechanisms, load balancing, circuit breaking (to avoid service
overload), and encryption between services.
●​ It provides detailed monitoring and tracing for better insight into application
performance and faults
●​ t separates network communication logic from business logic, allowing
developers to focus on their core app features.

Example:
Imagine an online store built with microservices: product catalog, user accounts,
shopping cart, payment, recommendations, etc. The service mesh handles all the
messaging between these services—making sure data flows securely, quickly, and with
resilience to failures.
Summary:
●​ A service mesh is the communication manager between microservices.
●​ It enhances security, observability, and reliability.
●​ Works behind the scenes without changing application code.
●​ Examples include Istio, Linkerd, and AWS App Mesh.

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is a secure

international messaging system that connects over 11,000 financial institutions in 200+
countries. It’s not a payment system but a channel that transmits standardized
messages instructing banks how to process cross-border financial transactions. This
helps ensure that money transfers are reliable, efficient, and secure, forming the
backbone of global banking.

Detailed Step-by-Step SWIFT Payment Workflow

1. Preparation
●​ Sender gathers information:
●​ Recipient’s full name and address.
●​ Recipient’s bank name, branch address, account number.
●​ SWIFT/BIC code of the recipient’s bank (an 8 or 11 character identifier).
●​ Routing code (if required).
●​ Purpose of transfer.
●​ Any additional documentation your bank requests.

2. Initiation
●​ The sender visits their bank (physical branch or online banking).
●​ A request for a SWIFT transfer (international wire payment) is made.
●​ The sender fills out a transfer form with all the required details.
●​ The sender reviews for accuracy and confirms the request, often completing a
verification step (such as an OTP or password).
3. Message Formation and Transmission
●​ The sending bank formats the payment instructions as a standardized SWIFT
message, such as an MT103 for customer credit transfer.
●​ The SWIFT message includes all beneficiary and transaction details.
●​ The message is routed using the recipient bank’s SWIFT/BIC code.
●​ The sending bank transmits the SWIFT message securely over SWIFTNet
(SWIFT’s private, encrypted network).

4. Intermediaries: Correspondent and Intermediary Banks

●​ Sometimes, the sender’s bank and recipient’s bank do not have a direct
relationship.
●​ The payment may go via one or more correspondent/intermediary banks
(“middlemen”) which hold Nostro/Vostro accounts for facilitating foreign
currency transactions.
●​ Nostro account: A bank’s own funds held in a foreign bank.
●​ Vostro account: A foreign bank’s funds held in the domestic bank.
●​ Each intermediary bank reviews the message, checks for regulatory compliance,
may deduct fees, and forwards it to the next institution

5. Processing and Settlement

●​ The recipient’s bank receives the SWIFT message through SWIFTNet.
●​ They verify all details:
●​ SWIFT code.
●​ Account details.
●​ Amount and currency.
●​ Funds are credited to the recipient’s account.
●​ Simultaneously, settlements are made between banks via adjustment of Nostro
and Vostro accounts.
6. Notification, Confirmation, and Completion
●​ The recipient’s bank notifies the account holder of credit.
●​ The sender’s bank may also notify the sender of successful completion.
●​ The process typically takes 2-5 business days, influenced by bank relationships,
compliance checks, holidays, accuracy of details, and possible involvement of
multiple banks.
●​ Both sender and recipient can trace the payment if there are delays, thanks to
SWIFT’s tracking and audit capabilities.

What is MT103?
●​ Officially called a Single Customer Credit Transfer, MT103 is used for transmitting
customer payment instructions through the SWIFT network.
●​ It contains all key details needed by the recipient bank to process and credit the
beneficiary’s account.
●​ Banks and customers can use MT103 as proof to track and confirm payments.
An MT103 is a standardized SWIFT message used by banks for international wire
transfers. It functions as a payment confirmation and carries detailed information about
a cross-border transaction. Think of it as a digital receipt that travels with your money
across banks worldwide.

Detailed Explanation of MT103

What is MT103?
●​ Officially called a Single Customer Credit Transfer, MT103 is used for transmitting
customer payment instructions through the SWIFT network.
●​ It contains all key details needed by the recipient bank to process and credit the
beneficiary’s account.
●​ Banks and customers can use MT103 as proof to track and confirm payments.
Core Components of MT103 Message:
An MT103 message is structured in blocks, mainly the Block 4 (Text Block) contains the
detailed transaction information with fields identified by "tags." Here's a breakdown of
key fields:

Tag Description Details

:20: Transaction Reference Number Unique identifier for the payment

:23
Bank Operation Code Usually "CRED" indicating credit transfer
B:

:32 Value Date, Currency, and Date funds are to be credited, currency code, and

A: Amount amount

:50
Ordering Customer Sender’s bank account and customer details
a:

:52 Sender’s bank’s SWIFT code (if different from sender

Ordering Institution (optional)
A: info)
 :53 Sender's Correspondent
Intermediary or correspondent bank details
a: (optional)

:54 Receiver’s Correspondent

Bank handling receiver’s end transaction
a: (optional)

:56 Intermediary Institution

Other involved banks in the transfer
a: (optional)

:57
Account With Institution Beneficiary’s bank SWIFT/BIC code
a:

:59
Beneficiary Customer Recipient’s account number and name
a:

:70: Remittance Information Payment details or invoice reference

:71 Specifies who pays transfer fees: sender (OUR), receiver

Details of Charges
A: (BEN), or shared (SHA)

Sender to Receiver Information

:72: Additional instructions or regulatory info
(optional)

(Note: the "a" in tags like 50a or 52a indicates different formatting options.)
How MT103 Works - Example Flow
●​ Sender initiates the payment with their bank.
●​ The bank generates the MT103 message including all sender, receiver, and
transaction details.
●​ MT103 is sent securely over SWIFTNet to the beneficiary bank.
●​ Intermediaries, if involved, process their parts of the payment.
●​ Receiver’s bank verifies and credits the recipient.
●​ Both sender and receiver can request a copy of the MT103 for confirmation or
dispute resolution.

{1:F01BANKBEBBAXXX1234567890}{2:I103BANKDEFFXXXXN}{4:
:20:REFERENCE12345
:23B:CRED
:32A:250815EUR123456,78
:50A:/12345678901234567890
JOHN DOE
:59:/09876543210987654321
JANE SMITH
:70:INVOICE 987654
:71A:SHA
-}
 ●​ :20: is the unique transaction ID.
●​ :32A: includes date, currency (EUR), and amount.
●​ :50A: contains sender’s account.
●​ :59: contains the receiver's account.
●​ :70: is payment purpose.
●​ :71A: indicates shared fees.

●​ MT103 messages might include many optional fields depending on transaction

complexity.
●​ MT103 differs from MT202 (which is a bank-to-bank transfer without customer
details).
●​ Newer standards introduce UETR (Unique End-to-End Transaction Reference) to
enhance traceability.

An MT199 is a versatile, free-format SWIFT message used by financial institutions for

general communication related to financial transactions when no other specific SWIFT
message type fits the purpose.

Key Characteristics of MT199:

●​ It is a non-payment message, meaning it does not initiate or transfer funds.
●​ Primarily used to send notifications, inquiries, confirmations, or instructions
related to transactions.
●​ Often serves to communicate about payment details, request additional
information, or notify delays.

●​ Can clarify or amend previous SWIFT messages related to payments or

transactions.
●​ Frequently used between banks for problem resolution or transaction status
updates.
Usage scenarios:
●​ Confirming payment details before processing an MT103 payment.
●​ Requesting additional or missing payment information.
●​ Notifying a delay or problem in processing a payment.
●​ Confirming receipt of funds for reconciliation.
●​ Sending special instructions related to ongoing transactions.

Structure of MT199:
It contains basic fields such as:
●​ :20: Transaction Reference Number (unique ID)
●​ :21: Related Reference (refers to the earlier related message)
●​ :79: Narrative or free text with detailed information
{1:F01BANKBEBBAXXX1234567890}{2:I199BANKDEFFXXXXN}{4:
:20:REFERENCE12345
:21:RELATEDREF67890
:79:Please confirm receipt of payment with reference number 987654321.
We have not yet received confirmation from your side.
-}

●​ {1:F01...} and {2:I199...}:​

Header blocks identifying the sending bank and message type (MT199).
●​ :20: Transaction Reference Number​
A unique identifier for this specific MT199 message for tracking purposes (e.g.,
REFERENCE12345).
●​ :21: Related Reference​
Refers to a related message or transaction, often linking this communication to a
prior payment or instruction (e.g., RELATEDREF67890).
●​ :79: Narrative / Comments​
Free text field where the sender can include any message or request (e.g., asking
to confirm receipt, provide additional info, or clarify a transaction).
What is Montran SFMS?
●​ Montran is a global provider of payment, cash, and liquidity management
solutions for banks. In India, Montran is a major supplier of payment engines for
RTGS, NEFT, and connected banking systems.
●​ SFMS (Structured Financial Messaging System) is an Indian messaging protocol
(developed by IDRBT) used for secure, electronic, standardized message
exchange within Indian banking for transactions like NEFT, RTGS, and Bank
Guarantees.

How ICICI Bank uses Montran and SFMS

●​ ICICI Bank utilizes Montran’s payment engines to process and manage NEFT,
RTGS, and other electronic transactions.
●​ These engines interface with the bank’s core systems and the external payment
infrastructure (NEFT/RTGS/ACH).
●​ Montran’s system structures, validates, and routes financial messages in SFMS
format, enabling secure, error-free electronic transactions and regulatory
compliance.

Workflow for a Typical Transaction:

1.​ Initiation:​
Customers initiate a payment via ICICI Bank’s platform—could be NEFT, RTGS, or
bank guarantee issuance.
2.​ Processing in ICICI’s Core Systems:​
Transaction details are captured and formatted by ICICI’s core banking.
3.​ Message Creation:​
Montran’s Payment Engine forms the SFMS message using the provided details.
●​ For NEFT/RTGS: includes sender/receiver details, amounts, IFSC codes,
etc.
●​ For Bank Guarantees: includes guarantee details, confirmation data, etc
 1.​ Validation:​
Message is validated for structure, content, and compliance standards per RBI
and IDRBT protocols.
2.​ Transmission to Switching/Settlement Centers:
●​ SFMS message sent to NPCI/RBI’s NEFT/RTGS switching system or (for
guarantees) directly to the beneficiary bank.
●​ Ensures secure, encrypted communication over the banking network.
3.​ Settlement and Acknowledgement:
●​ Funds/guarantees settled between banks.
●​ ICICI receives confirmation or failure messages via SFMS, which are
posted back into their systems and notifications sent to the customer.
●​ Archival and Auditing:
i.​ All message and transaction logs are stored for audit, compliance,
and regulatory reporting.

​
Technical Details:
●​ SFMS Format:
i.​ Layered, XML-like message definitions tailored for Indian payments
standards.
ii.​ Strong integration with RBI protocols; interoperability with
SWIFT/ISO 20022 for global transactions.
4.​ Payment Engine Functions:
●​ Multi-channel support: NEFT, RTGS, ACH, e-Bank Guarantees, and more.
●​ Automated compliance checks (sanctions screening, message validation).
●​ Routing and exception management.
●​ Real-time status updates and reconciliation.
5.​ Security:
●​ Messages encrypted and digitally signed.
●​ Complies with RBI and IDRBT guidelines for financial messaging security.
6.​ Channels:
●​ Web banking, corporate banking portals, branch interfaces, API-based
integrations.