Pega Application Architecture – Part 4: Integration Architecture

How does the Nexus banking application communicate with Core Banking, KYC, AML, Credit Bureau, Card, CRM, and other enterprise systems?

In the previous parts of this series, we designed the overall application architecture, Case Types, and Data Architecture for Alpha Bank. We established that Nexus is the banking application/product, while the underlying Pega class structure belongs to the Alpha organization.

But there is one major architectural question left: Where does the data actually come from?

A Customer may exist in a Customer Master system. An Account may belong to the Core Banking system. A credit score may come from a Credit Bureau. KYC information may come from a KYC provider. AML screening may be performed by an external AML platform. Card information may come from a Card Management platform.

Nexus should not try to become a copy of every one of these systems. Instead, Pega should provide a clean integration architecture that allows business processes to access the right information and invoke the right enterprise services when required.

This is where Integration Architecture becomes one of the most important parts of a Pega application architecture.

Pega Integration Architecture for Alpha Bank Nexus Banking Application

Pega Application Architecture – Part 4: How Nexus communicates with Core Banking, KYC, AML, Credit Bureau, Card, CRM, and other enterprise systems.

1. What Is Integration Architecture in Pega?

Integration Architecture defines how a Pega application communicates with systems outside of Pega.

For our Alpha Bank example, Nexus needs to communicate with systems such as:

Core Banking
Customer Master / CRM
KYC Provider
AML / Sanctions Screening
Credit Bureau
Card Management Platform
Document Management System
Notification Services

These systems may expose REST APIs, SOAP services, databases, messaging interfaces, or other integration mechanisms.

From a Pega architecture perspective, the important question is not simply:

"How do I call an API from Pega?"

The more important architectural question is:

"How do I design an integration that is reusable, secure, maintainable, resilient, observable, and independent of the business process?"

2. Alpha Bank Integration Scenario

Let's continue using the same Alpha Bank Nexus application from Parts 1–3.

Suppose John is a Relationship Manager and submits a LoanApplication Case.

Nexus needs to perform several activities:

Retrieve customer information.
Retrieve existing accounts.
Verify KYC information.
Perform AML / sanctions screening.
Retrieve the customer's credit score.
Evaluate loan eligibility.
Possibly create or update the loan in Core Banking.
Store or retrieve supporting documents.
Send notifications to the customer.

None of these external systems should need to understand how the Nexus Case Type is implemented.

Likewise, the LoanApplication Case should not contain endpoint URLs, authentication logic, HTTP headers, or raw API response structures.

That separation is one of the fundamental principles of good Pega integration architecture.

3. High-Level Integration Architecture

The architecture can be visualized as:

User / Channel
      ↓
Nexus Case Type
      ↓
Pega Data Page
      ↓
Request Data Transform
      ↓
Pega Connector
      ↓
External Enterprise System
      ↓
External Response
      ↓
Response Data Transform
      ↓
Data Page
      ↓
Case / Business Process

The important point is that the Case Type does not directly depend on the external API implementation.

Instead, the Data Page and integration layer provide the abstraction between the business process and the external system.

4. Nexus Is the Application Name — Alpha Is the Class Namespace

This is important because we established this naming model earlier in the architecture series.

Concept	Alpha Bank Design
Organization	Alpha
Application / Product	Nexus
Work classes	`Alpha-Banking-Work`
Data classes	`Alpha-Banking-Data`
Integration classes	`Alpha-Banking-Int`

Notice that Nexus is not part of the class names. Nexus is the application/product name.

5. Integration Class Architecture

For Alpha Bank, we can separate integration-specific artifacts under the Integration layer:

Alpha
 └── Alpha-Banking
      ├── Alpha-Banking-Work
      │    ├── CustomerOnboarding
      │    ├── AccountOpening
      │    ├── LoanApplication
      │    ├── KYCReview
      │    └── FraudReview
      │
      ├── Alpha-Banking-Data
      │    ├── Customer
      │    ├── Account
      │    ├── Loan
      │    ├── KYC
      │    ├── CreditScore
      │    ├── Card
      │    └── Document
      │
      └── Alpha-Banking-Int
           ├── Customer
           ├── CoreBanking
           ├── KYC
           ├── AML
           ├── CreditBureau
           ├── Card
           ├── DocumentManagement
           └── Notification

The exact class structure depends on the application design and reuse requirements, but the architectural separation is important:

Work represents business processes.
Data represents the logical business data model.
Int represents integration-specific implementation.

6. First Question: Who Owns the Data?

Before creating a connector, ask:

What system is the authoritative source for this information?

This is the System of Record (SOR) decision.

Business Data	Example Alpha SOR	Pega Usage
Customer	Customer Master / CRM	Retrieve customer information
Account	Core Banking	Retrieve balances and account details
KYC	KYC Provider	Verification / status
AML	AML Platform	Screening result
Credit Score	Credit Bureau	Credit decision input
Card	Card Platform	Card request/status
Case workflow	Nexus / Pega	Own workflow state and case lifecycle

This prevents a common architectural problem: duplicating the same business data in multiple systems and then trying to determine which copy is correct.

7. Why Data Pages Are So Important in Integration Architecture

A Data Page provides a reusable way for Pega to access data. It separates the business process from the details of the underlying data source.

For example:

LoanApplication
      ↓
D_CreditScore
      ↓
Credit Bureau Connector
      ↓
Credit Bureau API

The LoanApplication Case does not need to know:

the external endpoint
HTTP headers
OAuth configuration
external JSON structure
authentication details
request mapping
response mapping

Those concerns belong in the integration layer and Data Page configuration.

8. Alpha Bank Data Pages

Our Nexus application can expose reusable Data Pages such as:

Data Page	Purpose	Typical Parameter
`D_Customer`	Customer information	`CustomerID`
`D_Account`	Account details	`AccountNumber`
`D_KYC`	KYC verification	`CustomerID`
`D_CreditScore`	Credit score information	`CustomerID`
`D_AMLScreening`	AML screening result	`CustomerID`
`D_Product`	Bank products	ProductID
`D_Branch`	Branch information	BranchID

9. Data Page Configuration — What Do We Actually Configure?

When designing a Data Page, four important architectural decisions are:

Structure — Page or List.
Object Type — what logical data the page represents.
Edit Mode — Read-only, Editable, or Savable.
Scope — Thread, Requestor, or Node.

For example:

D_CreditScore

Structure: Page
Object Type: CreditScore
Edit Mode: Read-only
Parameter: CustomerID
Source: REST Connector

10. Parameterized Data Pages

Many enterprise Data Pages should be parameterized.

For example:


        D_Customer[CustomerID = "C100234"]

Another Case may use:


        D_Customer[CustomerID = "C100812"]

Parameterization allows the same logical Data Page to retrieve different customer instances.

However, architects should also consider parameter cardinality. If a Data Page receives thousands of unique parameters, caching every unique instance may provide limited benefit and can increase memory usage.

11. REST Integration in Pega

Suppose Alpha Bank's Credit Bureau exposes a REST API:

POST /credit-score

Request:
{
  "customerId": "C100234"
}

Response:
{
  "score": 742,
  "riskGrade": "A",
  "bureauStatus": "SUCCESS"
}

In Pega, the REST integration can be implemented through a REST Connector. Pega documentation describes the connector as the mechanism that sends the request to the external data source and processes the response.

The integration architecture should separate:

Logical Pega data model
External API request model
External API response model
Mapping between those models
Connector configuration

12. Request Data Transform

The Request Data Transform converts the Pega logical model into the structure expected by the external system.

For example:

Pega Property	External API Property
`.CustomerID`	`customerId`
`.SSN`	`taxIdentifier`
`.DateOfBirth`	`dob`

The business Case should not have to know that the Credit Bureau calls CustomerID something completely different.

13. Response Data Transform

The Response Data Transform performs the reverse mapping.

External API
    ↓
score = 742
riskGrade = "A"
    ↓
Response Data Transform
    ↓
.CreditScore = 742
.RiskGrade = "A"
    ↓
D_CreditScore
    ↓
LoanApplication

This mapping layer is extremely useful because the external API contract can evolve independently from the logical data model used by the business application, provided the mapping is maintained.

14. Complete Alpha Bank Example — Loan Application to Credit Bureau

Let's walk through the complete runtime flow.

John submits a LoanApplication.
The Case reaches the Credit Assessment stage.
The process requires the customer's credit score.
Pega references D_CreditScore.
The Data Page checks whether the requested data is available according to its configured scope and refresh behavior.
If the data must be loaded, the Data Page invokes its configured source.
The Request Data Transform builds the external request.
The REST Connector invokes the Credit Bureau.
The Credit Bureau returns the response.
The Response Data Transform maps the response to the Alpha logical data model.
The Data Page is populated.
The Case uses the credit score for the next business decision.

LoanApplication does not directly call the Credit Bureau. It requests data through the Data Page abstraction.

15. What About SOAP?

Not every enterprise banking system exposes REST.

Alpha Bank's Core Banking system may expose SOAP services, while a newer Credit Bureau may expose REST APIs.

From the business process perspective, the goal should still be the same:

Case → Data Page / Integration abstraction → External System

The underlying connector technology can vary without forcing the LoanApplication process to understand the protocol details.

16. Data Page Data Sources

A Data Page can be populated from different types of sources. Depending on the requirement and Pega version, commonly used sources include connectors, Data Transforms, Report Definitions, database lookups, activities, robotic automation, and aggregate sources.

Source	Alpha Bank Example
REST Connector	Credit Bureau API
SOAP Connector	Legacy Core Banking service
Report Definition	Data stored in Pega
Database Lookup	Specific locally managed reference data
Data Transform	Derived or transformed data
Aggregate Sources	Combining information from multiple sources when appropriate

17. Can One Data Page Use Multiple Sources?

Yes. Pega supports multiple data source configurations, including aggregate and conditional sourcing patterns.

For example, Alpha Bank could have:

D_Customer

        ┌── Customer Master API
        │
        ├── Secondary Customer Service
        │
        └── Other configured source

The exact pattern should be driven by business requirements, source ownership, availability, freshness, and operational behavior.

Multiple sources should not be added simply because Pega allows them. Every fallback or aggregation path introduces additional behavior that must be tested and monitored.

18. Synchronous Integration

A synchronous integration means the current process needs the external response before it can continue.

Example:

LoanApplication → Credit Bureau → Credit Score → Continue Credit Decision

If the credit score is required to make the next decision, the Case may need to wait for the response.

This makes the external system part of the response-time path, so timeout, availability, error handling, and user experience become important architectural considerations.

19. Asynchronous Integration

Not every integration needs to block the user.

Suppose a completed CustomerOnboarding Case needs to send a notification to an external enterprise service.

If the customer does not need to wait for that notification service, the work can be moved to background processing.

CustomerOnboarding
       ↓
Queue for Processing
       ↓
Queue Processor
       ↓
Notification API
       ↓
Email / SMS / Push

Current Pega guidance identifies Queue Processors as the modern mechanism for decoupled background processing, including asynchronous integrations, with configurable retry behavior and operational visibility.

When background processing can retry an operation, the operation should be designed with idempotency in mind.

20. Synchronous vs Asynchronous — How Do We Decide?

Question	Synchronous	Asynchronous
Is response immediately required?	Yes	No
Can user continue without response?	Usually no	Yes
Typical example	Credit score needed for decision	Notification / downstream update
Primary architectural concern	Response time and availability	Reliability, retry, status tracking

The decision should come from the business requirement rather than from a blanket rule that every API call must be synchronous or asynchronous.

21. Integration Authentication and Security

Integration security is different from user authentication.

When Nexus calls a Credit Bureau, the external system must authenticate the calling application or integration client.

Depending on the external contract, the integration may use:

OAuth 2.0
API keys
Basic authentication where supported and appropriate
Client certificates / mTLS
Other enterprise authentication mechanisms

Credentials, secrets, certificates, and tokens should not be hardcoded into Case logic or Data Transforms.

Authentication configuration should be managed through the appropriate Pega integration/security configuration and enterprise secret-management approach.

22. Headers, Correlation IDs and Traceability

Enterprise integrations usually need more than just a request body.

For example, Alpha Bank may need:

Authorization information
Correlation ID
Request ID
Content type
Client/application identification
API version

A useful integration design ensures that a business transaction can be traced across systems.

Case ID
   ↓
Correlation ID
   ↓
Nexus Integration
   ↓
Credit Bureau Request
   ↓
Credit Bureau Logs

This becomes extremely valuable when production support needs to answer: "What happened to John's credit check?"

23. Integration Error Handling

One of the biggest mistakes in integration design is treating every failure as the same type of error.

Type 1 — Transport / Infrastructure Failure

Examples include timeout, DNS failure, connection failure, TLS problem, or downstream system unavailable.

Type 2 — HTTP / Protocol Failure

Examples include HTTP 400, 401, 403, 404, 429, 500, or other protocol-level responses.

Type 3 — Business Failure

The API may successfully respond but indicate that the business operation failed.

HTTP success does not automatically mean business success.

For example:

HTTP 200

{
   "status": "FAILED",
   "reason": "Customer not eligible"
}

Pega must distinguish technical success from business outcome.

24. Retry Strategy

Retry should not mean:

Keep calling the API until it works.

A retry policy should consider:

Whether the failure is transient.
Whether retrying can create duplicate business operations.
How many retries are appropriate.
Delay between attempts.
Whether the operation is idempotent.
What happens after retries are exhausted.

For background processing, Queue Processors provide configurable retry behavior and can move failed work into a broken queue for administrative handling.

25. Idempotency — Very Important for Banking Integrations

Suppose Nexus sends a request to create a loan.

The external system creates the loan, but the network fails before Nexus receives the response.

Nexus may not know whether the loan was created.

If the integration simply retries the same request and creates another loan, we have a serious business problem.

Therefore, state-changing integrations should be designed with an appropriate idempotency strategy, such as a business transaction ID or idempotency key when supported by the external contract.

26. When Credit Bureau Processing Is Long-Running

Suppose the Credit Bureau takes a significant amount of time and the business process does not require an immediate response.

Instead of blocking the user's request, Nexus can use a background processing pattern.

LoanApplication
      ↓
Queue Processor
      ↓
Credit Bureau Connector
      ↓
Credit Bureau
      ↓
Response
      ↓
Update Case / Data
      ↓
Continue workflow

This pattern can improve responsiveness and isolate long-running external work from the user-facing request.

27. Reading Data vs Updating Data

There is an important architectural distinction between:

Getting information from an external system.
Changing information in an external system.

For example:

Operation	Alpha Bank Example
Read	Retrieve Account Balance
Read	Retrieve Credit Score
Update	Update Customer Address
Create	Create Loan in Core Banking

Savable Data Pages can be used when the logical data should be persisted through a configured save plan. The save configuration can map the logical data to the external request and invoke the appropriate connector or other persistence mechanism.

28. What We Should NOT Do

A common anti-pattern looks like this:

LoanApplication Flow
   ↓
Activity
   ↓
Hard-coded endpoint
   ↓
Authentication logic
   ↓
Build JSON manually
   ↓
Call external API
   ↓
Parse response
   ↓
Set 40 case properties

This makes the Case Type tightly coupled to the external system.

A better architecture is:

LoanApplication
   ↓
D_CreditScore
   ↓
Request Data Transform
   ↓
REST Connector
   ↓
Credit Bureau
   ↓
Response Data Transform
   ↓
D_CreditScore

29. Separation of Concerns

A clean Nexus architecture separates these concerns:

Layer	Responsibility
Work	Business process and Case lifecycle
Data	Logical business data model
Data Page	Reusable data access abstraction
Integration	Connector and external system communication
SOR	Authoritative external or internal source of business data

30. Do Not Make the External API Model Your Pega Business Model

This is a subtle but very important architecture principle.

Suppose the Credit Bureau returns:

{
  "bureauCustomerReference": "X123456",
  "riskIndicator": "A",
  "scoreValue": 742,
  "scoreVersion": "5.2",
  "bureauDecisionCode": "00"
}

The Nexus logical model may only need:

CreditScore
RiskGrade
BureauStatus

The Response Data Transform becomes the boundary between those models.

This is one of the reasons Data Transforms are important in integration architecture.

31. The Complete Integration Building Blocks

For a typical REST integration in Nexus, think about these building blocks:

Logical Data Object / Data Type
Data Page
Integration / API class where appropriate
REST Connector
Request Data Transform
Response Data Transform
Authentication configuration
Error handling
Timeout / retry strategy
Logging and monitoring
Security controls

Pega's integration examples commonly follow this pattern: configure the connector, configure the Data Page to use the external source, map the request, map the response, and then expose the resulting data to the application.

32. Alpha Bank Core Banking Integration

Core Banking is usually one of the most important systems in a banking architecture.

Nexus may need to retrieve:

Account details
Account status
Available balance
Transaction information
Loan information
Payment information

It may also need to perform controlled state-changing operations such as opening an account or creating a loan.

The architecture should clearly distinguish between:

Read integration → retrieve authoritative information
Write integration → request a business transaction in the SOR

State-changing operations require additional consideration for idempotency, transaction state, error recovery, and reconciliation.

33. KYC Integration

During CustomerOnboarding, Nexus may need to verify customer identity.

CustomerOnboarding
       ↓
D_KYC
       ↓
KYC Connector
       ↓
KYC Provider
       ↓
Verification Result
       ↓
D_KYC
       ↓
KYCReview / Next Stage

The Case can then make a business decision based on the normalized result rather than depending directly on the provider's raw response.

34. AML / Sanctions Integration

AML screening may be invoked during CustomerOnboarding, CustomerMaintenance, LoanApplication, or other relevant processes.

A typical logical model could contain:

ScreeningStatus
MatchFound
RiskLevel
ScreeningReference
ReviewRequired

The external AML provider may return a much more complex response. Nexus should normalize the information needed by the business process.

35. Credit Bureau Integration

Credit Bureau integration is a good example of why integration architecture must be designed carefully.

A LoanApplication may need:

Credit score
Risk grade
Credit report reference
Decision indicators
Response status

These values can be exposed through a logical Data Page such as:

D_CreditScore[CustomerID]

This allows different Case Types to reuse the same integration capability instead of implementing the Credit Bureau call independently in every Case.

36. Reuse the Integration — Do Not Rebuild It in Every Case

Suppose CustomerOnboarding needs customer information. AccountOpening also needs customer information. LoanApplication needs customer information. CardRequest needs customer information.

We should not create four independent customer APIs.

One reusable logical data access pattern can support multiple Case Types.

CustomerOnboarding ──┐
AccountOpening ──────┤
LoanApplication ─────┼──→ D_Customer ──→ Customer Master
CardRequest ──────────┘

37. Integration Performance — Data Page Caching

External API calls are expensive compared with reading data already available in memory or locally accessible storage.

Data Pages can cache data according to their configured scope and refresh strategy.

This means the architecture needs to ask:

How frequently does this data change?
How fresh must the data be?
Who can share the cached value?
How many unique parameters will the Data Page receive?
What happens when the data becomes stale?

For example, a branch reference list may tolerate much longer caching than a customer's current account balance.

38. Data Page Scope and Integration Design

Pega Data Pages support different scopes:

Thread — data associated with the current thread.
Requestor — data that can be shared by threads for the requestor.
Node — data shared for requestors on the same Pega node.

Scope should be selected based on the data's sharing requirement, volatility, freshness requirements, and performance characteristics.

For example:

Data	Possible Consideration
Current Credit Score	Short-lived / case-specific freshness
Customer-specific data	Parameterized access with appropriate scope
Branch reference data	Potentially broader caching because it changes less frequently

39. Timeout Design

Every synchronous external integration should have a clearly defined timeout strategy.

The timeout should be based on the service-level agreement and user experience requirements rather than an arbitrary value.

If the external system is slow, allowing the Pega requestor to wait indefinitely is not an acceptable architecture.

Instead, the design should define:

Expected response time
Maximum acceptable wait
Failure behavior
Retry behavior where appropriate
Fallback or manual-review behavior where applicable
Monitoring and alerting

40. Integration Monitoring and Observability

An integration is not complete when the API call works in development.

We also need to know what happens in production.

Useful operational information includes:

Integration name
Case ID
Correlation ID
Request timestamp
Response timestamp
Response time
HTTP status
Business response status
Error category
Retry count
External transaction/reference ID

Sensitive information such as credentials, access tokens, and unnecessary personal or financial data should not be written into logs.

41. Integration Audit

For banking applications, it is often important to understand not only the final Case result but also what happened during external interactions.

For example:

Case: LA-100234

KYC:
   Request sent
   Response received
   Result: VERIFIED

AML:
   Request sent
   Response received
   Result: CLEAR

Credit Bureau:
   Request sent
   Response received
   Score: 742

The exact audit implementation depends on the enterprise's compliance and data-retention requirements.

42. Integration Security Is More Than Authentication

We should think about security at multiple levels:

Who is allowed to trigger the Case?
Who is allowed to perform the business action?
What data can the user see?
How does Pega authenticate to the external system?
How is data transported securely?
How are secrets protected?
What sensitive data is written to logs?

This connects directly with the Security Architecture covered in the previous security series.

Integration security and application authorization are related, but they solve different problems.

43. Sensitive Banking Data

Alpha Bank may process highly sensitive information such as:

Social Security Number / Tax Identifier
Account numbers
Credit information
Customer identity information
Financial information
KYC documents

Therefore, the integration architecture should consider:

Encryption in transit
Encryption at rest where required
Least-privilege access
Property-level protection where appropriate
Secure credential management
Log masking
Audit requirements
Data retention requirements

44. Integration Performance Problems to Watch For

Problem 1 — N+1 API Calls

A Case retrieves 100 accounts and then makes another API call for each account. This can create 101 external calls.

Problem 2 — Repeated Calls

Multiple UI sections independently request the same customer information.

Problem 3 — Wrong Data Page Scope

A Data Page is configured with a scope that does not match the intended sharing and freshness behavior.

Problem 4 — High-Cardinality Parameters

Thousands of unique Data Page parameters can reduce caching benefits and increase resource usage.

Problem 5 — Synchronous Calls for Non-Critical Work

Long-running notification or downstream processing unnecessarily blocks the user request.

45. What Happens When an External System Is Down?

This should be designed before production, not after the first outage.

For each integration, define:

What happens when the endpoint is unavailable?
Can the request be retried?
Can the Case continue?
Should the Case wait?
Should it move to manual review?
Should the work be queued?
How is the failure surfaced to operations?
How can the transaction be reconciled later?

There is no single answer for every integration. A Credit Bureau failure may require a different business response from a Notification Service failure.

46. Do Not Hide Integration Status

Suppose CustomerOnboarding calls KYC and the request fails.

We should not simply leave the Case looking like everything completed successfully.

A logical status model may distinguish:

Not Started
In Progress
Completed
Business Rejected
Technical Failure
Manual Review Required

The exact values should be driven by the business process and operational requirements.

47. What Should the Alpha-Banking-Int Layer Contain?

Conceptually, the Integration layer contains artifacts needed to communicate with external systems.

Alpha-Banking-Int
│
├── CoreBanking
│    ├── Account API
│    ├── Loan API
│    └── Transaction API
│
├── Customer
│    └── Customer API
│
├── KYC
│    └── KYC Verification API
│
├── AML
│    └── Screening API
│
├── CreditBureau
│    └── Credit Score API
│
├── Card
│    └── Card Management API
│
└── DocumentManagement
     └── Document API

The actual rules and artifacts will depend on the Pega version, integration mechanism, and enterprise architecture.

48. External API Versioning

External APIs change.

Suppose the Credit Bureau moves from:

/credit-score/v1

to:

/credit-score/v2

A well-designed integration architecture should minimize the impact of this change on business Case Types.

Ideally, the Case continues to request:

D_CreditScore[CustomerID]

while the integration implementation handles the external API evolution.

49. Integration Testing

Integration testing should not only test the happy path.

For Credit Bureau, test at least:

Valid customer
Invalid customer
Successful response
Business rejection
Authentication failure
Authorization failure
Timeout
Connection failure
Malformed response
Rate limiting
Duplicate request
Retry behavior

The objective is to verify both the connector and the business behavior of the Case when the integration succeeds or fails.

50. Troubleshooting a Pega Integration

When an integration fails, do not immediately assume that the connector is the problem.

Trace the architecture from the Case outward:

Is the Case reaching the integration step?
Is the Data Page being invoked?
Are the required parameters populated?
Is the Data Page source configured correctly?
Did the Request Data Transform populate the connector request?
Did the connector execute?
Was authentication successful?
What HTTP/protocol response was returned?
Did the Response Data Transform execute?
Was the logical Data Page populated?
Did the Case interpret the result correctly?

51. Rule-Level Implementation Checklist

When implementing a new Alpha Bank integration, the architect/developer should identify the following artifacts.

Artifact	Purpose
Data Type / Data Object	Logical business data model
Data Page	Reusable data access layer
REST/SOAP Connector	External communication
Request Data Transform	Pega → External mapping
Response Data Transform	External → Pega mapping
Authentication / Connection Configuration	Secure connectivity
Error Handling	Technical and business failures
Monitoring / Audit	Production visibility and traceability

Exact rule names and authoring screens vary by Pega version and by the integration technology being used, so the implementation should follow the corresponding version-specific Pega tooling.

52. Complete Runtime Architecture

                    ALPHA BANK NEXUS
                           │
                           ▼
                    Case Type / Process
                           │
                           ▼
                     Data Object
                           │
                           ▼
                      Data Page
                           │
                 ┌─────────┴─────────┐
                 │                   │
                 ▼                   ▼
        Request Data Transform   Cache / Scope
                 │
                 ▼
              Connector
                 │
       ┌─────────┼──────────┬──────────┐
       ▼         ▼          ▼          ▼
   Core Bank    KYC        AML    Credit Bureau
       │         │          │          │
       └─────────┴──────────┴──────────┘
                 │
                 ▼
       External Response
                 │
                 ▼
       Response Data Transform
                 │
                 ▼
             Data Page
                 │
                 ▼
           Nexus Case
                 │
                 ▼
          Business Decision

53. Integration Architecture Principles for Nexus

1. Keep Case Types independent of external API details.

2. Use Data Pages as a reusable data access abstraction.

3. Keep request and response mapping separate from business workflow.

4. Identify the authoritative System of Record before implementing the integration.

5. Choose synchronous or asynchronous processing based on business need.

6. Design timeout, retry, idempotency, and recovery behavior explicitly.

7. Secure credentials and sensitive banking information.

8. Build monitoring and traceability into the integration design.

9. Design for API version changes and external system failures.

10. Reuse integration capabilities across Case Types instead of rebuilding them.

54. Common Integration Architecture Mistakes

Calling external APIs directly from multiple Case processes.
Hardcoding endpoint URLs in business logic.
Hardcoding credentials or tokens.
Using Activities for everything instead of appropriate Pega integration patterns.
Duplicating the same customer integration for every Case Type.
Making every integration synchronous.
Using asynchronous processing without designing retry and idempotency.
Ignoring external API versioning.
Logging sensitive customer information.
Not distinguishing technical failure from business rejection.
Using a Data Page scope that does not match the required sharing/freshness behavior.
Ignoring high-cardinality parameterized Data Pages.
Failing to define recovery and reconciliation procedures.

55. How to Explain This in a Pega Interview

"In our Alpha Bank Nexus application, we separate business Case Types, logical data, and external integrations. The Case Type does not directly call external systems. We use Data Pages as the reusable data access abstraction. A Data Page can use a REST or SOAP connector as its source, with Request and Response Data Transforms mapping between the Pega logical model and the external API model. For example, a LoanApplication can use D_CreditScore to retrieve credit information from a Credit Bureau. The integration layer handles connectivity, authentication, mapping, error handling, retry behavior, monitoring, and external-system concerns. For work that does not need to block the user, we can use asynchronous processing such as Queue Processors. This keeps the Case architecture loosely coupled and makes integrations reusable and easier to maintain."

56. The Mental Model to Remember

When you design any integration in Pega, think about it in this order:

What business capability needs the data?
What logical Data Object represents it?
Who owns the data?
What is the System of Record?
Can a Data Page abstract the access?
What connector/protocol is required?
How do we map the request?
How do we map the response?
Does the Case need the response immediately?
What happens if the external system fails?
How do we secure and monitor it?
How will the integration evolve?

CASE → DATA → DATA PAGE → CONNECTOR → EXTERNAL SYSTEM → RESPONSE → CASE

57. Putting the First Four Parts Together

At this point, the Nexus architecture is becoming much clearer.

Part 1
Application Architecture
        ↓
What is Nexus and how is the application structured?

Part 2
Case Type Architecture
        ↓
What business processes does Nexus manage?

Part 3
Data Architecture
        ↓
What business data does Nexus use?

Part 4
Integration Architecture
        ↓
Where does the data come from and
how does Nexus communicate with other systems?

        ↓

Core Banking
KYC
AML
Credit Bureau
CRM
Cards
Documents
Notifications

This gives us the foundation for the next major architectural concern: how we secure the application, cases, data, and integrations.

Key Takeaway

Integration Architecture is not simply about creating a REST or SOAP connector.

In a well-designed Pega application, the business process remains focused on the business while the integration architecture handles communication with external systems.

For Alpha Bank's Nexus application:

Case Types manage the business process.
Data Types define the logical business data.
Data Pages provide reusable data access.
Connectors communicate with external systems.
Data Transforms translate between logical and external models.
Integration architecture handles security, resilience, monitoring, and change.

Pega Application Architecture Series

Part 1 — Application Architecture: Designing Nexus for Alpha Bank

Part 2 — Designing Case Types for the Nexus Banking Application

Part 3 — Data Type & Data Architecture

Part 4 — Integration Architecture

Part 5 — Security Architecture

Part 6 — Runtime, Deployment & Operations

PegaHelp — Pega Application Architecture Series