What Actually Happens When You Open Your Banking App? The client-server model, packets, the big picture.

Network Guide · Level 1: Foundations · Lesson 1 of 21

You tap your banking app on the bus, and about a second later your balance appears. So what happens when you open your banking app? A lot more than it looks like.

Short answer: when you open your banking app, your phone gets an IP address, uses DNS to find the bank, sends traffic through your router and across the internet, opens a TCP connection on port 443, verifies the bank’s certificate with TLS, and then the bank’s firewall, load balancer, and servers confirm who you are and return your balance.

It feels like one action. It isn’t. In that second, your phone confirmed a network connection, asked where your bank lives, passed through a dozen devices owned by different companies, checked that it was talking to the real bank, and held a conversation with several systems you will never see.

I use this single tap as the map for the whole subject. Every topic in this guide appears somewhere in it: IP addressing, DNS, switching, routing, NAT, firewalls, TLS, and redundancy. In this lesson I’ll walk you through the trip once, at a high level. Later lessons zoom into each stop.

Same journey, any app. Open Gmail, join a Zoom call, or load a school portal, and the same steps happen. Only the destination changes. The banking example is one case of a universal pattern.

From my infrastructure desk to you: don’t try to memorize every protocol yet. First understand the journey. Once you can see where the packet is going, the individual technologies start to make sense.

The big idea: clients and servers

Nearly everything you do online follows the client-server model. Your phone is the client: it asks for something. The bank’s systems are the servers: they answer. The network is the road in between.

Here is the one problem I want you to keep in mind: how does a request get from the client to the right server, and how does the answer get back reliably, privately, and to the right place?

Think like an infrastructure analyst: when you understand who is asking, who is answering, and what sits between them, you already have the skeleton of most network troubleshooting.

Your phone is the client—but before it can ask the bank for anything, how does it get an address that allows the network to recognize it?

Step 1: Your phone has an address

Before your phone can talk to anyone, it needs an IP address, the network equivalent of a return address on an envelope. On Wi-Fi, the router usually hands one out automatically using DHCP. Along with the address, your phone receives a subnet mask (which addresses count as “local”), a default gateway (the exit from your local network), and a DNS server (the phone book, coming next). On cellular, your carrier does the equivalent.

Typical home address: something like 192.168.1.23. That is a private address. It only has meaning inside your own network.

Think of it like this: checking into a hotel. The front desk gives you a room number (your IP address), points out the lobby exit (the default gateway), and hands you the building directory (the DNS server).

Zoom in later: Lesson 3 (IP addresses) and Lesson 5 (DHCP).

Your phone now has an address and an exit, but it still does not know the bank’s IP address. So how does a human-readable bank name become a routable number?

Step 2: Finding the bank with DNS

People type names. Networks route by numbers. Your phone needs to translate the bank’s server name into an IP address, and it does that by asking a DNS resolver. The resolver may be your router, your internet provider, or a public service. Your phone might already have the answer cached from last time.

DNS is a trust point. If an attacker could feed your phone a forged answer, your traffic would be steered toward the wrong server. That is why I always stress the identity check in Step 5.

Think of it like this: your phone’s contacts app. You tap “Mom” and the phone looks up the number and dials it. DNS does the same for websites. Many devices and browsers now also encrypt these lookups (DNS over HTTPS or DNS over TLS), so people on the path cannot easily read them.

Zoom in later: Lesson 4 (DNS).

Sr. IT perspective: when a user says, “The internet works, but this website doesn’t,” DNS is one of the first places I mentally place on the troubleshooting path.

Now your phone knows the bank’s IP address. But the bank is not inside your home or office network. How does the packet actually leave your network and start crossing the internet?

Step 3: Leaving your network

The bank’s IP address is not on your local network, so your phone hands the packet to the default gateway, usually your router. The router does two jobs here:

• NAT (Network Address Translation): it swaps your private source address for the router’s public address and remembers the swap, so the reply finds its way back to your phone.
• Routing: it forwards the packet toward your internet provider.

From there, the packet crosses a series of routers. Each router reads only the destination address, checks its routing table, and passes the packet to the next hop. No single device knows the full path. You can see a version of it yourself in the hands-on section below.

Think of it like this: an office mailroom plus the postal system. Staff drop mail at the mailroom, which stamps the company’s street address on outgoing envelopes and logs who sent what, so replies reach the right desk (NAT). The mail then moves through sorting centers that each read only the destination ZIP code and pass it along (routing).

Zoom in later: Lesson 10 (routing) and Lesson 11 (NAT).

From an infrastructure point of view: this is where I stop thinking about “the application” and start thinking about next hop, route, gateway, and path.

Routing can get the packet to the bank, but how do your phone and the bank establish a reliable conversation instead of just sending unrelated packets at each other?

Step 4: Opening a reliable connection with TCP

Banking data cannot arrive scrambled or incomplete, so your phone uses TCP, which numbers the data, confirms delivery, and re-sends anything lost. Before any real data moves, the two sides perform a quick three-way handshake:

1. Phone to server: “I’d like to talk” (SYN)
2. Server to phone: “Okay, I’m ready” (SYN-ACK)
3. Phone to server: “Great, starting now” (ACK)

The connection goes to port 443, the standard door for secure web traffic (HTTPS). A server can offer many services at once, and the port number says which one you want.

Think of it like this: certified mail with tracking, started by a short phone call (“Hello?” “Yes, I’m here.” “Great.”). TCP numbers every page and re-sends any that go missing. Port 443 is the extension number: the building has many departments, and 443 reaches the secure-web desk.

Modern note: many apps and browsers now use QUIC (HTTP/3), which runs over UDP on port 443 and builds encryption in. TCP with TLS is still the standard teaching model and a common fallback. The goals are the same: reliable, encrypted delivery.

Zoom in later: Lesson 6 (ports, TCP, and UDP).

A connection is now established, but connection does not automatically mean trust. How does your phone know the server on the other end is really the bank?

Step 5: Proving who the bank is with TLS

Next comes TLS, the technology behind the padlock. The bank’s server presents a digital certificate. Your phone checks that a trusted authority issued it, that it matches the bank’s name, and that it hasn’t expired. If everything checks out, both sides agree on encryption keys.

From this point on, anyone in the middle, such as the owner of the Wi-Fi hotspot or your internet provider, can generally see which server you are connecting to but not what you are sending. Your login token, your balance, and your transactions travel encrypted.

Think of it like this: verifying a bank’s identity before you hand over anything. You ask for ID issued by an authority you trust (the certificate), then you both switch to sealed, tamper-proof envelopes (encryption) that the postal workers along the way cannot open.

Zoom in later: Lesson 14 (TLS and certificates).

My infrastructure habit: never treat “I can reach the server” and “I trust the server” as the same statement. Connectivity and identity are different checks.

TLS protects the connection, but what actually happens once your encrypted request reaches the bank’s infrastructure?

Step 6: Inside the bank

Your request arrives at the bank’s edge, where several systems stand in a row:

• DDoS protection or a content delivery network absorbs floods of junk traffic.
• A firewall allows only the traffic the bank expects.
• A load balancer picks a healthy application server from a pool, so no single server is a point of failure.

The application server then calls an authentication service to confirm who you are. This is the point where your saved login, Face ID, or a one-time code comes into play. It then asks internal systems and databases for your balance.

In a well-designed bank network, the public-facing servers and the systems that hold customer records sit in separate network segments. A request does not travel straight from the internet to the database.

Think of it like this: a bank branch. A security guard at the door (firewall), a greeter who sends you to the shortest teller line (load balancer), a teller who confirms who you are (authentication), and a vault in a staff-only back corridor (a database in a separate segment).

Zoom in later: Lesson 12 (firewalls), Lesson 16 (segmentation), and Lesson 17 (redundancy).

The bank has processed the request. But how does the answer make its way back to the exact phone and session that started the conversation?

Step 7: The answer comes back

The response retraces the journey, though not always along the same path. It is normal for return traffic to take a different route than the request did. Your phone decrypts the data, and the app displays your balance.

Think of it like this: the teller hands your receipt back across the same lobby, though the courier may take a different route home.

The complete journey works only when every checkpoint works. So what does a failure at each checkpoint actually look like to the person holding the phone?

Where things can go wrong

Every stop on the journey is also a place where something can fail.

One-to-one troubleshooting advice: if you’re trying to build real infrastructure judgment, don’t jump randomly from one possible cause to another. Follow the packet. The order of the journey gives you the order of the investigation.

Knowing where failure can happen is useful, but how do I turn this map into a repeatable troubleshooting method when a user simply says, “The app isn’t loading”?

Why this map matters for IT work

When someone tells me “the app isn’t loading,” I walk this same journey in order: check the address, then DNS, the route, the port, the certificate, and finally the server. Working step by step beats guessing, and it is exactly what the next lesson formalizes with the OSI and TCP/IP models.

My troubleshooting order: Address → DNS → Route → Port → Certificate → Server.

The same packet journey matters differently depending on whether you’re help desk, sysadmin, network engineer, security analyst, or still learning. Where should you focus?

What this means for your IT role

You’ve now seen the journey from several IT roles. If you remember only three ideas from this lesson, which three should stay with you?

Three takeaways

1. One tap is many systems. Each device on the path does one job, and none of them sees the whole picture.
2. Names become addresses, addresses become paths, and paths need trust. That is DNS, then routing, then TLS.
3. Security and reliability are built in at every step. They are not added at a single point.

You have read the journey. Now can you explain it without looking back? The quick check will show you.

Quick check

1. What four pieces of information does DHCP typically give your phone?
2. Why does your phone send bank-bound traffic to the default gateway instead of directly to the bank?
3. What does a TLS certificate prove, and what does it not prove?

Answers:

1. An IP address, a subnet mask, a default gateway, and a DNS server.
2. Because the bank’s address is not on the local network, and the gateway is the exit.
3. It proves the server presenting it controls a certificate issued for that name by a trusted authority. It does not prove that the organization behind the name is trustworthy in every other way.

Understanding the theory is useful, but can you see any part of this journey from your own computer right now? Yes—you can.

Try it yourself

Open a command prompt or terminal and run these two commands:

• nslookup example.com shows the IP address DNS returns for a name.
• tracert example.com (Windows) or traceroute example.com (macOS and Linux) lists the routers your packets pass through on the way.

Count the hops and note how the names change as the path leaves your network and crosses providers.

Do this like an analyst: don’t worry if some hops do not reply. The point here is to start connecting the diagram in your head with the path your own traffic actually takes.

You can now follow the basic journey yourself. But what are the most common questions readers still ask about banking apps, ports, Wi-Fi, DNS, and connectivity?

Frequently asked questions

What happens when you open a banking app?

Your phone gets an IP address, uses DNS to find the bank, sends traffic through your router and across the internet, opens a TCP connection on port 443, verifies the bank’s certificate with TLS, and then the bank’s firewall, load balancer, and servers confirm who you are and return your balance.

Does a banking app use its own network?

No. It uses the public internet over Wi-Fi or cellular. TLS encryption keeps the contents private, and the bank’s internal systems sit behind its edge defenses.

What port does a banking app use?

Typically port 443, the standard port for secure web traffic. That is HTTPS over TCP, or UDP when the app uses QUIC (HTTP/3).

Is public Wi-Fi safe for banking apps?

TLS stops the hotspot owner from reading your data, but risks remain: rogue hotspots, fake login pages, and malware on your device. Use cellular or a network you trust for sensitive tasks, keep your phone and app updated, and never ignore a certificate warning.

What is the difference between DNS and DHCP?

DHCP gives your device its network settings, including its IP address. DNS translates a name, such as your bank’s website, into an IP address.

Why does my banking app say it can’t connect?

Any step can fail: no address, a DNS problem, a broken route, a certificate error, or an outage at the bank. The “Where things can go wrong” table above shows what each failure looks like.

You have seen the concepts in context. Which technical terms should you now be able to recognize when they appear in the rest of this guide?

Key terms I introduced

Client, server, IP address, DHCP, subnet mask, default gateway, DNS, NAT, routing table, TCP, three-way handshake, port 443, TLS, certificate, QUIC, firewall, load balancer, network segment.

These terms are easier to remember when they have a place on a model. So how do we organize this entire journey into layers without turning it into a memorization exercise?

Next lesson

Lesson 2: The OSI and TCP/IP Models, Without the Memorization. We take this same journey and organize it into layers, so every device and protocol has a place on the map.

Why should you continue into Lesson 2? You already understand the journey. The next lesson gives you the framework that lets you place DHCP, DNS, IP, TCP, TLS, routers, switches, and applications into the correct layer—and troubleshoot them more systematically.

Related reading on US WealthTech

If you want the risk side of this story, start with Is Face ID Safe for Banking?, Are Your Browser Extensions Safe for Banking?, and Is it safe to link bank accounts?.