Subscribe

» » Pega Blueprint in Action: Designing the Alpha Bank Nexus Onboarding App with GenAI

Pega Blueprint in Action: Designing the Alpha Bank Nexus Onboarding App with GenAI


This is the first post in a new hands-on series. Instead of writing about Pega Constellation and the DX API from documentation, we're building one real application — Alpha Bank Nexus, the same fictional bank from the application architecture series — and showing every screen along the way. This post covers step one: using Pega Blueprint to go from a plain business description to a generated application design.

What's in this post

What Pega Blueprint actually is

Pega Blueprint (at pega.com/blueprint) is Pega's GenAI-driven application design tool. You describe a business process in plain English, and Blueprint proposes an application design for it: case types, process stages and steps, a case data model, the personas who work the case, and a catalog of optional features it thinks are relevant to your industry. It is not a code generator and it does not build working software by itself. What it produces is a structured design — a starting point you review, edit, and then either hand to a developer or export directly into a Pega Platform instance as a new application shell.

That last part matters for this series: Blueprint's output can be downloaded as a package and imported into a real Pega instance, which is exactly what we'll do in the next post.

Setting it up: industry, department, and a business description

Blueprint starts by narrowing the domain before it asks about your actual process. We went through:

  1. Industry — Banking
  2. Sub-industry — Retail Banking
  3. Department/function — a dropdown of banking-specific functions (Collections, Customer Service, Financial Crime, Lending, Onboarding, Operations, Sales...). We picked Onboarding.

Once we picked Retail Banking, Blueprint also suggested a single "application purpose" template — CLM/KYC – Client Onboarding for Financial Services — which was close enough to accept as-is.

Then came the part that actually matters: a free-text functional description of the process. This is the only place you're really "programming" Blueprint, so we wrote out the real scenario, matching the Alpha Bank Nexus architecture from Part 1:

Alpha Bank is building Nexus, a workflow orchestration application for retail banking. The first process is Customer Onboarding: a new customer applies to open an account. The bank collects the customer's personal information, verifies their identity, runs a KYC review and an AML sanctions screening, assesses risk, and requires approval from a compliance analyst and a manager for higher-risk applicants before creating the customer record and account and notifying the customer. Personas involved: the Customer submitting the request, a Bank Analyst who reviews KYC and standard applications, and a Manager who approves higher-risk cases. Nexus orchestrates the process; the Core Banking system remains the system of record for account data, and separate KYC and AML services provide screening results.

That's it — one paragraph. Click Generate, and Blueprint spends roughly 20–30 seconds working through a visible checklist: "Blueprint AI analyzing your requirements," "Leveraging AI-backed industry insights," "Generating optimized agentic-Workflows," "Architecting intelligent data foundations," "Blueprint AI personalizing for..." It's a real wait, not a spinner for show — each of those steps corresponds to a distinct part of the output that shows up afterward.

What Blueprint generated: case types and stages

From that one paragraph, Blueprint proposed five case types, not one:

  • Customer Onboarding — the parent case: end-to-end onboarding, closing on successful customer creation.
  • KYC Review — identity and document verification, resolved when checks complete or fail.
  • AML Screening — sanctions/watch-list screening, resolved on delivery of a screening result.
  • Risk Assessment — evaluates collected information and screening results to route to the right approval track.
  • Onboarding Approval — compliance analyst review, escalating to a manager for high-risk cases.

That's a more realistic decomposition than most people sketch by hand on the first pass — it mirrors exactly the kind of parent-case-with-child-cases structure the earlier architecture series recommended, without us asking for it explicitly.

Opening the Customer Onboarding case type showed a full case lifecycle: five primary stages — Intake → Verification → Review → Fulfillment → Completion — plus an alternate Rework stage. Each stage already has concrete steps, not placeholders:

  • Intake: Collect Personal Info, Request Digital Consent, Acknowledge Submission
  • Verification: Verify ID, Run KYC Screening, Run AML Screening, Risk Assessment, Summarize Screening
  • Review: Analyst Review (Assign Analyst, Review Screening, Decision Routing), Manager Approval (Approve High-Risk)
  • Fulfillment: Create Customer Record, Open Account, Generate Welcome Pack
  • Completion: Send Outcome, Notify Stakeholders, Close Case

Each step is also typed — some are plain data-capture steps, some are decision steps, one ("Summarize Screening") is flagged as an AI-assisted step. You can add, reorder, or delete steps directly in this view before anything is generated further.

The case data model, and a field worth noticing

Blueprint also generated a case data model for Customer Onboarding: fields like Customer onboarding title, Customer type, Risk assessment result, Application submitted date, KYC status, AML screening status, Compliance analyst (a User Reference type), Manager approval required, and Customer notification sent.

One field stood out: Risk assessment result is typed as Prediction, not plain text. That's Blueprint tagging a field as something a decisioning or AI model would populate, rather than something a user types in — a small but genuine hint at how Pega expects risk scoring to be wired in later, and a preview of the kind of AI-architecture detail this series will get into.

The gap: Blueprint didn't add our integrations on its own

This is the most important honest finding from this session. Our description explicitly mentioned KYC, AML, and Core Banking as external systems. Blueprint's Data & Integrations step generated three data objects — Customer, Account, Application — but the Integrations section came back with a count of zero.

Blueprint does not infer external systems from prose the way it infers data fields and stages. Integrations are something you add explicitly, one at a time, through an "Add Integration System" dialog (choose a system type — Custom, or a named connector like SAP, Salesforce, Snowflake, Experian, and others — then name it and describe what it provides). We added three: KYC Service, AML Screening, and Core Banking, each with a short description of what it returns.

This is a useful thing to know before you rely on Blueprint for a real design review: it will confidently build you a case lifecycle and a data model from a paragraph, but it will not go looking for the systems you merely mentioned in passing. You have to declare them.

Personas — including one that isn't a person

Blueprint generated four personas: Customer, Bank Analyst, Manager — matching what we described almost word for word — and a fourth one we didn't ask for: Application Control Agent, described as "an always-on autonomous agent that spans your entire application... understands requests instantly, executes the right work, and orchestrates the right outcome across every part of your Pega Infinity application."

That fourth persona is Blueprint's way of baking an agentic/GenAI actor into the design from the start, not bolted on later. It's a good sign of where Pega is pushing application design, and a natural bridge to a future post in this series on Pega's agentic architecture.

The features catalog

The Features step is a checklist of optional capabilities Blueprint thinks are relevant to a CLM/KYC banking app, grouped by category: third-party integrations like Entity Verification and Screening: PEP, Sanctions and Adverse Media Screening (naming real providers such as Moody's/VeDaaS and Refinitiv World-Check as examples), AI features like Risk Overview and Document Requirements Optimization (both off by default), Risk Scoring & Rating under Risk & Compliance (on by default), and grouping features like Entity Group Management. We left the defaults as Blueprint proposed them, since the point of this post is to show what it suggests out of the box.

Blueprint checks its own work

Before letting us download anything, Blueprint ran its own best-practice check and surfaced two findings in a "Blueprint recommendations" dialog:

  • No access settings — flagged against the Customer, Bank Analyst, and Manager personas: we hadn't defined who can see or do what.
  • No referenced External SOR — flagged against all Data & Integrations instances: even after we added the three integrations, Blueprint noted that our data objects didn't explicitly reference a System of Record.

Both are legitimate architecture gaps, not busywork. This is genuinely useful: it's the same review a solutions architect would do on a first-pass design, automated. We chose "Download anyway" so we could show the un-fixed state in this post, but a real project would go back and close these before moving on.

A quirk worth being honest about

In the generated Summary, the Organization name field came back as "Internet Service Provider" — clearly a stray default from Blueprint's template library, unrelated to anything we typed. Everything else in the summary (industry, sub-industry, department, language, and the actual architecture) was correct. It's a small reminder that generated output should be read, not rubber-stamped, even when the interesting parts are right.

Exporting: a PDF and a deployable app

The Summary page ends with two real export options:

  • Download PDF — a shareable design document: the business description, the architecture diagram (personas, workflows, data objects), suitable for review with a team that isn't in Pega.
  • Download Blueprint — a package that "can be imported to your Pega Platform as a new app." This is the file that turns a design into a starting application.

We downloaded both. The PDF is for sharing and record-keeping; the Blueprint package is what we'll import into a real Pega instance in the next post.

What's next

Post two in this series imports this exact Blueprint package into a Pega instance and checks what actually shows up: which case types, stages, and data objects arrive intact, what Blueprint could only sketch, and what still has to be built by hand — access roles for the three personas, real integrations behind our three placeholder systems, and the risk-scoring model behind that "Prediction" field. From there we move into Constellation views and the DX API traffic those views generate, which is where this series is ultimately headed.

Filed under:

No comments:

Post a Comment