API & Business Logic 101: How Systems Really Work

Understanding APIs, HTTP requests, and business logic from the ground up - explained for fraud analysts with no technical background

What Is an API? (The Restaurant Analogy)

API stands for "Application Programming Interface" - but that's a confusing name. Think of it as a waiter in a restaurant:

The Complete Restaurant Experience

You're sitting at a table (your computer/phone) and you want to order food. You can't walk into the kitchen and cook it yourself - there are rules and processes.

The waiter (the API) is your go-between:

You tell the waiter what you want ("I'd like the chicken sandwich")
The waiter writes it down and takes it to the kitchen
The kitchen (the bank's computer system) prepares your order
The waiter brings back either your food or says "Sorry, we're out of chicken"

In banking terms:

You want to check your account balance
The mobile app sends your request to the bank's API
The API asks the bank's systems for your balance
The API sends back your balance to display on your phone

Why APIs Exist

Without APIs: Every app would need direct access to every database and system (chaos!)

With APIs: There's an organized way for different systems to communicate safely and securely.

How APIs Actually Work: Step-by-Step

Every API Transaction Has 4 Parts

1. The Request (What You're Asking For)

When you tap "Check Balance" on your banking app, here's what really happens:

Your Phone → Banking App → Internet → Bank's API

The app sends a message like:

"Please give me the balance for account #12345"
"The user has already logged in with token abc123"
"This request is coming from their registered phone"

2. Authentication (Proving Who You Are)

The API doesn't just trust anyone. It checks:

"Are you really John Smith?" (Username/password, fingerprint, etc.)
"Is this request coming from John's registered device?"
"Is John's session still active, or did he log in 3 days ago?"

3. Processing (Doing the Work)

Once the API confirms you are who you say you are:

It connects to the bank's database
It looks up your specific account
It retrieves your current balance
It checks if you have permission to see this information

4. Response (Sending Back the Answer)

The API sends back either:

Success: "Account balance is $1,247.83"
Error: "Account not found" or "Access denied"

A Real Example: Transferring Money

What you do: Open your banking app, select "Transfer Money," choose accounts, enter $500, tap "Send"

What actually happens:

Step 1: App sends request to API
"POST /transfer-money
User: John Smith (token: abc123)
From: Checking Account #12345  
To: Savings Account #67890
Amount: $500"

Step 2: API checks everything
- Is John really logged in? ✓
- Does checking account #12345 belong to John? ✓  
- Does John have $500 in checking? ✓
- Are both accounts active? ✓

Step 3: API processes the transfer
- Subtract $500 from checking
- Add $500 to savings  
- Record the transaction
- Update both account balances

Step 4: API responds
"Success: Transfer completed
New checking balance: $1,247.83
New savings balance: $2,847.83"

HTTP: The Language Computers Use to Talk

HTTP (HyperText Transfer Protocol) is like the postal system for the internet. Every message between computers follows HTTP rules, just like every letter follows postal rules (needs an address, stamp, return address).

HTTP Request Types (Like Different Types of Mail)

GET = "Please show me something" (like requesting your bank statement)
POST = "Please create something new" (like opening a new account)
PUT = "Please update something" (like changing your address)
DELETE = "Please remove something" (like closing an account)

What an HTTP Request Looks Like

Method: POST (creating something)
URL: https://bank.com/api/transfer-money
Headers: 
  - Authorization: "I'm John Smith, token abc123"
  - Content-Type: "I'm sending data in JSON format"
  
Body (the actual request):
{
  "from_account": "12345",
  "to_account": "67890", 
  "amount": 500.00,
  "memo": "Rent payment"
}

Think of this like addressing an envelope:

URL = Street address where the letter goes
Method (POST) = Type of mail (regular letter, certified, etc.)
Headers = Return address and special instructions
Body = The actual letter content inside

What Is Business Logic? (The Rules That Run Everything)

Business logic = All the rules and processes that make a business work properly.

Real-World Business Logic Examples

Banking Rules:

"Customers cannot withdraw more money than they have in their account"
"International transfers over $10,000 need additional verification"
"ATM withdrawals are limited to $500 per day"
"Savings accounts can only have 6 withdrawals per month"

E-commerce Rules:

"Discount codes can only be used once per customer"
"Free shipping applies to orders over $50"
"Returns must be requested within 30 days"
"Credit card payments require CVV verification"

Insurance Rules:

"Claims over $10,000 need manager approval"
"You can't file a claim for the same incident twice"
"Policies must be active for 30 days before claims are accepted"

Where Business Logic Gets Enforced

Think of business logic like security guards at different checkpoints:

Customer Request
    ↓
Frontend Validation (First security guard)
"Does this look reasonable?"
    ↓  
API Gateway (Second security guard)
"Is this user allowed to make this request?"
    ↓
Business Logic Layer (Head of security)
"Does this follow all our business rules?"
    ↓
Database (The vault)
"Store the transaction if everything is approved"

Why Business Logic Matters for Fraud

Criminals look for places where business logic is weak or missing:

Example 1: Race Condition

Bank rule: "Check account balance before allowing withdrawal"
Criminal exploit: Send 100 withdrawal requests simultaneously
What happens: Some requests might be processed before the balance check updates
Result: Account goes negative, bank loses money

Example 2: Workflow Bypass

Insurance rule: "All claims need manager approval"
Criminal exploit: Find an API endpoint that skips the approval step
Result: Unauthorized claims get paid automatically

API Security: How Systems Try to Protect Themselves

Authentication: "Who Are You?"

Like showing ID at a bar:

Something you know: Password
Something you have: Phone for SMS codes
Something you are: Fingerprint, face recognition

API Authentication Methods:

Username/Password: Basic but can be stolen
Tokens: Like temporary ID badges that expire
Multi-Factor: Requires two or more forms of ID

Authorization: "What Can You Do?"

Like having different levels of access in a building:

Lobby level: Anyone can enter
Office floors: Need employee badge
Executive floor: Need special clearance
Server room: Need highest security clearance

API Authorization Examples:

Regular user: Can view their own account
Customer service: Can view any account but not transfer money
Manager: Can approve large transactions
System admin: Can access all functions

Rate Limiting: "Slow Down!"

Like speed limits on highways:

Purpose: Prevent systems from being overwhelmed
Example: "Each user can make maximum 100 requests per hour"
Why it matters: Stops automated attacks from making millions of requests

Input Validation: "Is This Request Safe?"

Like security screening at airports:

Check format: Is the account number the right length?
Check content: Is the transfer amount a positive number?
Check limits: Is the transfer amount within daily limits?
Check permissions: Is the user allowed to access this account?

Why Criminals Love Attacking APIs

APIs Are Direct Access to Money and Data

Traditional fraud: Trick a human into doing something wrong API fraud: Trick the computer system directly

Examples of What Criminals Can Do:

Account takeover: Use stolen credentials to access accounts via API
Business logic bypass: Skip verification steps in the process
Rate limit evasion: Make thousands of attempts to crack passwords
Parameter manipulation: Change request data to access other accounts

Why APIs Are Vulnerable

They're often less protected than websites (no human oversight)
They process requests automatically (no human to spot suspicious activity)
They're designed for efficiency (sometimes security is sacrificed for speed)
Business logic flaws are hard to detect with traditional security tools

Red Flags: How to Spot API Fraud

Unusual Request Patterns

Normal user behavior:

Logs in once, checks balance, makes a transfer, logs out
Requests spaced out naturally (human typing/thinking time)
Consistent geographic location

Suspicious API behavior:

Hundreds of login attempts per minute
Requests coming faster than humanly possible
Same user "logging in" from 20 different countries simultaneously
Unusual request sequences (like checking thousands of account numbers)

Business Logic Violations

Examples to watch for:

Multiple large transfers right after password change
Accounts suddenly having negative balances
Users performing actions they shouldn't have permission for
Transaction patterns that violate business rules

Technical Anomalies

Error rates suddenly spiking
Unusual parameter values in requests
Requests coming from suspicious IP addresses
API calls that bypass normal user interface flows

Investigating API Fraud: A Step-by-Step Guide

Step 1: Identify the Suspicious Activity

Look for:

Unusual spikes in API traffic
High error rates or failed authentication attempts
Customer complaints about unauthorized activities
Alerts from fraud detection systems

Step 2: Gather the API Evidence

Collect all relevant API logs:

Request timestamps and durations
Source IP addresses and geographic locations
User authentication tokens and session data
Complete request parameters and response codes
Error messages and system responses

Step 3: Reconstruct the Attack Timeline

Map out exactly what happened:

When did the attack start?
What was the sequence of API calls?
Which business rules were violated?
How much money or data was affected?

Step 4: Analyze the Business Impact

Determine:

Financial losses from fraudulent transactions
Compromised accounts and affected customers
Business processes that were exploited
System vulnerabilities that were exposed

Step 5: Document and Report

Create comprehensive documentation:

Complete timeline of events
Technical details of the attack method
Business logic vulnerabilities exploited
Recommendations for preventing future attacks

Key Takeaways for Fraud Analysts

APIs Are Everywhere

Every time you:

Check your bank balance
Make an online purchase
Send a text message
Use a mobile app

...there's an API involved.

APIs Are Crime Scenes

When financial fraud happens, the evidence is often in API logs:

What requests were made?
When were they made?
Where did they come from?
What responses were given?

Understanding APIs Helps You:

Follow the digital money trail more effectively
Understand how criminals bypass security measures
Identify suspicious patterns in system logs
Work better with technical teams during investigations
Recommend security improvements based on attack methods

Remember: You Don't Need to Be a Programmer

You need to understand:

How APIs work conceptually (the restaurant analogy)
What business logic is (the rules that should be followed)
How to spot when something is wrong (patterns and red flags)
How to investigate API fraud (gathering and analyzing evidence)

APIs might seem technical, but they're really just another way criminals try to steal money. Understanding them gives you a huge advantage in detecting and investigating modern fraud.

All Categories