Below is a strong first white-paper draft you can adapt for CorebaseIT, LinkedIn, or a longer PDF. I grounded it in the IEEE article ENWAR: A RAG-Empowered Multi-Modal LLM Framework for Wireless Environment Perception, which argues that vanilla LLMs are limited by generic training, outdated knowledge, hallucinations, and weak handling of multi-modal/domain-specific inputs, while RAG improves factual accuracy by retrieving relevant domain context before generation.

From Wireless Environment Awareness to Payment Intelligence

Applying RAG-Empowered LLM Architectures to POS, SoftPOS, and E-Commerce Payment Systems

Abstract

Large Language Models are becoming powerful reasoning interfaces for complex technical systems. However, in high-trust domains such as payments, banking, and e-commerce, a generic LLM is not enough. A payment system cannot rely on probabilistic answers, outdated knowledge, or unsupported reasoning. It needs factual grounding, auditability, domain context, latency awareness, and clear separation between explanation and execution.

The IEEE ENWAR framework proposes a RAG-empowered multi-modal LLM architecture for wireless environment perception. Its core idea is simple but powerful: transform raw environment signals into structured context, retrieve the most relevant domain knowledge, and then allow the LLM to generate grounded, human-interpretable situational awareness.

This white paper translates that principle into the payment domain. Instead of GPS, LiDAR, and camera inputs, a payment platform has transaction events, device telemetry, merchant profile data, customer behavior, issuer/acquirer responses, fraud signals, chargeback history, EMV data, SoftPOS attestation, and support interactions. A RAG-based payment intelligence layer can transform these signals into grounded explanations, operational recommendations, merchant-facing insights, and risk-assist workflows without allowing the LLM to become the payment decision engine itself.

The proposed architecture is not “LLM decides whether to approve a payment.” That would be the wrong starting point. The stronger approach is: deterministic systems and certified payment components continue to execute the transaction, while RAG-grounded AI explains, contextualizes, investigates, assists, and improves operational decision-making around the payment lifecycle.

⸻

Why LLMs Alone Are Not Enough for Payments

LLMs are excellent at language, summarization, pattern recognition, and reasoning over text. But payments are not just text. They are event-driven, regulated, latency-sensitive, security-sensitive systems.

A vanilla LLM has several limitations that matter directly in POS and e-commerce:

1.1 Generic knowledge is not payment knowledge

A general model may understand the words “authorization,” “issuer,” “fraud,” “chargeback,” or “3DS,” but that does not mean it understands a specific acquirer stack, merchant configuration, terminal capability, SoftPOS SDK behavior, EMV response code, or internal risk rule.

Payment knowledge is highly contextual. The same decline reason can mean different things depending on:

card scheme,
issuer behavior,
merchant category,
country,
transaction amount,
channel,
authentication method,
terminal capability,
previous attempts,
fraud score,
3DS outcome,
SoftPOS device integrity status.

Without retrieval from the correct operational context, the LLM will produce plausible but potentially wrong explanations.

1.2 LLMs can hallucinate

In payments, hallucination is not a cosmetic issue. A fabricated explanation can mislead a support agent, merchant, risk analyst, or compliance reviewer.

For example, a model might confidently say:

“The transaction was declined because the customer failed 3DS authentication.”

But the real reason may have been:

issuer decline, insufficient funds, expired card, unsupported terminal capability, SoftPOS attestation failure, or merchant configuration mismatch.

A payment AI system must therefore answer from evidence, not from probability alone.

1.3 LLMs do not naturally know what changed today

Payment systems change constantly:

new risk rules,
new BIN behavior,
new merchant configurations,
new SDK versions,
updated terminal capabilities,
acquirer routing changes,
scheme bulletins,
fraud attack patterns,
incident reports,
support tickets,
settlement exceptions.

A model trained months ago cannot know what happened this morning unless the system retrieves fresh operational knowledge.

1.4 LLMs are not designed for certified transaction execution

POS and SoftPOS systems have strong compliance boundaries. EMV processing, PIN handling, NFC transaction flow, key management, attestation, and cryptographic operations must remain inside certified and controlled components.

The LLM should not handle PAN, PIN, cryptographic keys, or sensitive cardholder data. It should not replace EMV logic, authorization logic, or the certified SDK. Its role should be carefully scoped around interpretation, support, analytics, workflow assistance, and human-readable explanation.

⸻

The Key Lesson from ENWAR

The ENWAR article introduces a RAG-empowered multi-modal LLM framework for wireless environment perception. The important architectural idea is not limited to wireless networks.

The principle is:

Convert raw domain signals into structured textual representations, index them in a domain-specific knowledge base, retrieve the most relevant context, and use the LLM to generate grounded, human-interpretable situational awareness.

In ENWAR, the raw signals are wireless environment inputs such as GPS, LiDAR, and camera data. These are transformed into textual representations, chunked, embedded, stored in a knowledge base, retrieved by semantic search, ranked, and then used by the LLM to generate grounded insights.

In payments, we can apply the same pattern.

The equivalent raw signals are:

transaction authorization events,
POS terminal telemetry,
SoftPOS attestation results,
SDK logs,
fraud engine outputs,
merchant configuration,
3DS authentication results,
issuer response codes,
acquirer routing decisions,
settlement and reconciliation records,
chargeback data,
customer support conversations,
device and app version metadata,
historical incident reports,
regulatory and scheme documentation.

The goal is payment situational awareness.

Not just:

“Why did this transaction fail?”

But:

“What happened, what evidence supports it, what system component was involved, what is the likely business impact, what should the merchant or support team do next, and how confident are we?”

⸻

Proposed Architecture: Payment-Aware RAG Layer

A practical RAG-based payment intelligence system can be divided into two pipelines.

3.1 Knowledge Formation Pipeline

This is the offline or near-real-time process that prepares the system’s memory.

Step A — Payment Data Transformation

Raw payment events are transformed into normalized, safe, textual representations.

Examples:

Authorization event

{ “event_type”: “authorization_decline”, “amount”: “57.80 EUR”, “channel”: “ecommerce”, “merchant_id”: “M123”, “issuer_response”: “05”, “three_ds_status”: “authenticated”, “fraud_score”: 0.72, “risk_action”: “review”, “routing_path”: “acquirer_A”, “timestamp”: “2026-06-10T10:41:23Z” }

SoftPOS device event

{ “event_type”: “softpos_attestation”, “device_model”: “Pixel 8”, “sdk_version”: “4.01.25”, “attestation_provider”: “Google Play Integrity”, “attestation_result”: “GREEN”, “security_action”: “NONE”, “nfc_status”: “available”, “battery_optimization”: “ignored”, “timestamp”: “2026-06-10T10:39:02Z” }

Support ticket

{ “event_type”: “merchant_support_ticket”, “merchant”: “Restaurant merchant”, “issue”: “Contactless payments fail above 50 EUR”, “reported_device”: “Samsung S21”, “region”: “ES”, “related_component”: “SoftPOS PIN flow”, “status”: “open” }

The key is to convert operational signals into consistent, searchable context while masking sensitive data.

Step B — Chunking and Embedding

The transformed payment data is split into coherent chunks:

per transaction,
per payment session,
per terminal,
per merchant,
per incident,
per support case,
per SDK version,
per risk rule,
per regulatory topic.

Each chunk is embedded into a vector representation and stored in a vector database.

Possible indexes:

transaction knowledge base,
merchant configuration knowledge base,
SoftPOS device telemetry knowledge base,
fraud and chargeback knowledge base,
support and incident knowledge base,
regulatory and scheme knowledge base,
SDK and release notes knowledge base.

Step C — Domain Knowledge Base

The system should combine operational data with curated domain knowledge:

internal payment architecture documentation,
EMV and scheme rules,
SoftPOS SDK documentation,
MPoC/CPoC constraints,
acquiring and settlement rules,
fraud rule explanations,
merchant onboarding requirements,
known incident playbooks,
support macros,
troubleshooting guides.

This creates a payment-specific retrieval layer that grounds the LLM in the actual business and technical context.

⸻

Prompt Interpretation and Response Generation

When a user asks a question, the AI system should not immediately generate an answer. It should first retrieve evidence.

Example prompt:

“Why are this merchant’s Tap to Pay transactions failing above €50?”

The system would retrieve:

recent failed payment attempts,
amount distribution,
SDK logs,
PIN prompt events,
device attestation events,
merchant terminal configuration,
app version,
known SDK issues,
support tickets,
relevant SoftPOS flow documentation.

Then the LLM generates an answer such as:

“The failures appear related to the PIN-required flow triggered above the contactless CVM threshold. The transaction reaches the SDK, NFC read succeeds, and device attestation is green. However, the PIN entry step is not completed successfully on app version X. This pattern appears only for transactions above €50 and only on devices using SDK version Y. Recommended next steps: reproduce with logging build, verify online PIN UI theme injection, check SDK callback handling after PIN submission, and compare with a known working device.”

This is valuable because the answer is:

contextual,
evidence-based,
operationally useful,
explainable,
bounded by retrieved data.

⸻

Payment Use Cases

5.1 Merchant Support Copilot

A RAG-based support copilot can help support agents answer merchant questions faster and more accurately.

Example questions:

“Why was this transaction declined?”
“Why are Tap to Pay payments failing on this device?”
“Why did settlement not match the authorization amount?”
“Why is this merchant seeing more soft declines than usual?”
“What changed after the latest SDK release?”

The copilot should retrieve payment events, configuration, logs, and documentation before answering.

The result is not just a chatbot. It becomes an operational investigation assistant.

5.2 Fraud Analyst Assistant

Fraud detection systems already generate scores. The harder problem is explaining the decision and reducing false positives.

A RAG-grounded fraud assistant can summarize:

transaction pattern,
merchant history,
customer behavior,
velocity signals,
device signals,
historical chargebacks,
similar fraud cases,
rule triggers,
model explanation,
recommended action.

Instead of saying:

“High fraud risk.”

It can say:

“This transaction is unusual because the customer attempted three cards within six minutes, the shipping country differs from the BIN country, the merchant has seen a recent increase in first-time high-value orders, and two similar transactions from the same device fingerprint became chargebacks last week.”

This makes fraud decisions easier to review and defend.

5.3 Smart Decline Explanation

Payment declines are expensive. They create lost revenue, merchant frustration, and support tickets.

A RAG system can classify and explain declines:

issuer decline,
authentication failure,
risk rejection,
merchant configuration issue,
acquirer routing issue,
terminal capability mismatch,
SoftPOS device integrity issue,
network timeout,
duplicate transaction,
expired session.

It can also suggest next actions:

retry with 3DS,
use another card,
contact issuer,
check merchant configuration,
update app version,
rebind terminal,
verify device integrity,
reroute through another acquirer.

This is especially useful for merchant dashboards.

5.4 SoftPOS and Tap to Pay Diagnostics

SoftPOS systems generate rich technical signals:

device model,
Android version,
NFC availability,
attestation result,
SDK version,
activation status,
PIN flow result,
transaction amount,
CVM requirement,
battery optimization status,
Google Play Integrity or Zimperium result,
app distribution channel,
logs and callbacks.

A RAG-based diagnostic assistant can answer:

“Is this a device problem, SDK problem, merchant configuration problem, or payment authorization problem?”

This is directly applicable to Tap to Pay operations.

5.5 E-Commerce Payment Orchestration Assistant

For e-commerce, the system can assist with:

3DS routing,
retry strategy,
payment method recommendation,
acquirer routing analysis,
conversion optimization,
fraud review,
abandoned payment analysis,
refund and chargeback investigation.

The AI should not autonomously change routing rules without control. But it can recommend:

“For this merchant, issuer declines increased after routing was moved to Acquirer B. Transactions authenticated with 3DS are still being declined at authorization. Consider testing fallback routing for BIN range X and monitoring approval rate over 24 hours.”

5.6 Compliance and Audit Assistant

A RAG system can help compliance teams answer:

“Why was this transaction blocked?”
“Which rule triggered this review?”
“What evidence supports this decision?”
“Was the customer affected by an automated decision?”
“Can we reconstruct the decision path?”

This is where faithfulness becomes critical. Every generated claim should trace back to retrieved evidence.

⸻

Multi-Modal Payments: The Payment Equivalent of GPS, LiDAR, and Camera

In wireless systems, multi-modal sensing combines different views of the physical environment.

In payments, multi-modal intelligence combines different views of the transaction environment.

ENWAR Modality Payment Equivalent Purpose GPS Transaction metadata Where, when, how much, which merchant, which channel LiDAR Device and infrastructure telemetry What the terminal, SDK, network, or app observed Camera Behavioral and support context What the user, merchant, or support conversation reveals Wireless knowledge base Payment knowledge base EMV, scheme rules, risk logic, SDK docs, incidents Line-of-sight analysis Payment path analysis Can the payment flow complete without blockage? Obstacle detection Failure cause detection What prevents approval, capture, settlement, or reconciliation?

This mapping is powerful.

A payment transaction is not a single event. It is a path through a system:

customer → checkout → authentication → risk engine → acquirer routing → issuer authorization → capture → settlement → reconciliation → dispute lifecycle.

AI can help understand where the path was blocked.

⸻

Proposed Reference Architecture

7.1 Layer 1 — Certified Payment Execution

This layer remains deterministic and controlled.

Includes:

POS app,
SoftPOS SDK,
EMV kernel,
NFC stack,
PIN entry,
cryptographic operations,
authorization API,
risk engine,
acquirer processor,
settlement system.

The LLM does not execute payment-critical logic.

7.2 Layer 2 — Event and Context Collection

Collect normalized events from:

payment gateway,
POS terminal,
SoftPOS SDK,
merchant backend,
fraud engine,
3DS server,
support platform,
settlement system,
monitoring tools.

Sensitive data must be tokenized, masked, or excluded.

7.3 Layer 3 — Payment Knowledge Base

Store:

transaction summaries,
merchant profiles,
risk rule documentation,
SDK documentation,
operational playbooks,
incident history,
support resolutions,
scheme and compliance references.

Use vector search plus metadata filters.

Metadata filtering is essential. A payment answer often depends on:

merchant,
country,
payment method,
date,
SDK version,
acquirer,
card scheme,
transaction channel.

7.4 Layer 4 — Retrieval and Ranking

The system retrieves the most relevant chunks and ranks them by:

semantic similarity,
freshness,
merchant relevance,
transaction proximity,
source trust level,
regulatory priority,
operational severity.

For payment systems, retrieval should prefer authoritative sources over merely similar ones.

A scheme rule, internal incident report, or actual transaction log should outrank a generic support article.

7.5 Layer 5 — LLM Reasoning and Explanation

The LLM generates:

explanation,
summary,
recommended next action,
confidence level,
evidence list,
escalation path.

It should also say when it does not know.

A good payment AI answer should include:

what happened,
why it likely happened,
what evidence supports it,
what is uncertain,
what to check next,
what not to do.

7.6 Layer 6 — Human and System Controls

For high-impact actions, the system should require human approval.

Examples:

changing fraud thresholds,
blocking a merchant,
refunding a transaction,
changing acquirer routing,
disabling a terminal,
modifying risk rules,
sending customer-facing explanations.

The AI can recommend. The payment platform controls execution.

⸻

Evaluation Metrics for Payment RAG

The ENWAR article uses KPIs such as answer relevancy, context recall, correctness, and faithfulness. These translate well to payment systems.

8.1 Answer Relevancy

Does the answer address the actual payment question?

Example:

Question:

“Why did this merchant’s SoftPOS transaction fail?”

Bad answer:

“Contactless payments are convenient and secure.”

Good answer:

“The transaction failed after NFC read because the SDK requested online PIN and the PIN result callback was not completed.”

8.2 Context Recall

Did the system retrieve the right evidence?

For payments, this means retrieving:

the right transaction,
the right merchant configuration,
the right SDK version,
the right risk event,
the right issuer response,
the right support ticket,
the right incident report.

Poor context recall is dangerous because the LLM may answer from incomplete evidence.

8.3 Correctness

Is the answer factually correct?

For example, if the issuer response was “insufficient funds,” the system should not explain the decline as a fraud rejection.

Correctness should be measured against ground-truth operational data.

8.4 Faithfulness

Are all claims supported by retrieved context?

This is one of the most important metrics for payment AI.

A faithful answer says:

“The logs show attestation passed, NFC read succeeded, and the failure occurred after PIN prompt.”

An unfaithful answer says:

“The customer probably cancelled because they were confused.”

Unless that is in the evidence, it should not be stated as fact.

8.5 Payment-Specific KPIs

Additional payment KPIs should include:

false explanation rate,
unsupported claim rate,
escalation accuracy,
mean time to resolution reduction,
support deflection rate,
fraud analyst review time,
merchant satisfaction,
latency overhead,
sensitive-data leakage rate,
audit trace completeness,
compliance review pass rate.

⸻

Latency: The Real-Time vs Near-Time Split

Payments have strict latency requirements. Authorization cannot wait for a large model to reason through logs and documentation.

Therefore, the architecture should split AI usage into two paths.

9.1 Real-Time Path

Used during transaction authorization.

Characteristics:

deterministic,
low latency,
rule-based or compact ML,
no large LLM in the critical path,
certified components remain isolated.

Possible AI use:

lightweight fraud model,
risk score,
routing hint,
device integrity check,
anomaly detection.

9.2 Near-Time Explanation Path

Used after or around the transaction.

Characteristics:

RAG-based,
richer context,
human-readable,
support and analyst oriented,
suitable for investigation and explanation.

Possible AI use:

decline explanation,
fraud case summary,
SoftPOS diagnostics,
merchant insight,
support response draft,
incident correlation.

This distinction is crucial. The LLM should not slow down payment authorization. It should make the system more understandable after the deterministic path has done its job.

⸻

Edge and Cloud AI for POS and SoftPOS

The ENWAR article discusses hierarchical architectures using smaller edge models and larger cloud models. This maps naturally to POS and SoftPOS.

10.1 Edge AI

On-device or near-device models can perform lightweight tasks:

classify local SDK errors,
detect device state anomalies,
summarize local logs,
identify repeated NFC failures,
detect onboarding problems,
provide offline troubleshooting hints.

For SoftPOS, this must be carefully designed so the AI does not access sensitive cardholder data or interfere with certified SDK boundaries.

10.2 Cloud AI

Cloud LLMs can handle heavier reasoning:

cross-merchant incident detection,
fraud pattern analysis,
support case summarization,
documentation retrieval,
compliance explanation,
merchant dashboard insights,
acquirer routing analysis.

10.3 Hybrid Pattern

A strong architecture is:

small local model for immediate classification, cloud RAG model for deeper explanation.

Example:

device detects repeated NFC timeout,
sends safe diagnostic summary,
cloud RAG retrieves known device issues and SDK release notes,
support agent receives grounded recommendation.

⸻

Security, Privacy, and Compliance Boundaries

A payment RAG system must be secure by design.

11.1 Do Not Send Sensitive Card Data to the LLM

The system should exclude or tokenize:

PAN,
CVV,
PIN,
track data,
cryptographic keys,
raw EMV sensitive data,
personally identifiable data unless strictly required and legally allowed.

11.2 Use Evidence-Based Answers

Every operational answer should include source references internally.

The system should be able to say:

based on transaction event X,
based on SDK log Y,
based on merchant configuration Z,
based on incident report N.

11.3 Separate Suggestion from Execution

The AI can recommend:

“Check merchant routing configuration.”

But it should not automatically:

change routing, block the merchant, refund the customer, or alter risk rules.

11.4 Keep Audit Logs

For every AI-generated answer, store:

user prompt,
retrieved context IDs,
model version,
response,
confidence,
user action,
final resolution.

This is essential for regulated environments.

⸻

Example: RAG for a Failed SoftPOS Transaction

User question

“Why did transaction 8472 fail on Tap to Pay?”

Retrieved context

Transaction amount: €63.20
NFC read: successful
CVM required: online PIN
SDK version: 4.01.25
Device: Samsung S21
Attestation: GREEN
Security action: NONE
Failure step: PIN entry callback timeout
Similar tickets: three merchants reported failure above €50 after SDK UI update
Known issue: theme injection incomplete in PIN screen

Grounded AI response

“The transaction did not fail because of NFC or device integrity. The NFC read completed and attestation returned GREEN with no security action. The failure occurred after the SDK requested online PIN, which is expected for this amount. The PIN callback timed out. Similar cases were reported after the SDK UI update, and the known workaround is to verify the new SDK UI theme injection for the PIN screen. Recommended next step: reproduce with a logging build, confirm whether the PIN view is displayed, and compare against a device running the previous SDK.”

This is the kind of answer a generic LLM cannot safely produce without retrieval.

⸻

Example: RAG for E-Commerce Decline Intelligence

User question

“Why did approval rate drop for Merchant X yesterday?”

Retrieved context

Approval rate dropped from 89% to 74%
Drop concentrated in French BIN ranges
Most declines are issuer response 05
3DS authentication success rate unchanged
Fraud rejection rate unchanged
Routing changed from Acquirer A to Acquirer B at 09:00
Similar incident occurred two months ago with same acquirer
No checkout errors detected

Grounded AI response

“The approval-rate drop appears related to issuer/acquirer authorization behavior rather than checkout, 3DS, or fraud rejection. The decline increase starts after the routing change to Acquirer B and is concentrated in French BIN ranges. Since 3DS success and fraud rejection rates remained stable, the most likely next step is to test fallback routing for the affected BIN ranges and compare issuer response distribution against Acquirer A.”

This turns operational data into actionable payment intelligence.

⸻

Implementation Roadmap

Phase 1 — Internal Knowledge Assistant

Start with non-sensitive documentation:

payment architecture,
support playbooks,
SDK documentation,
incident reports,
integration guides,
merchant onboarding guides.

Use case:

internal Q&A for engineers and support.

Risk level: low.

Phase 2 — Transaction Explanation Assistant

Add masked transaction events and merchant configuration.

Use cases:

decline explanation,
failed payment investigation,
SoftPOS troubleshooting,
support case drafting.

Risk level: medium.

Phase 3 — Fraud and Risk Analyst Assistant

Add fraud signals, chargeback history, and risk rule explanations.

Use cases:

fraud case summaries,
false positive analysis,
chargeback pattern investigation,
risk rule tuning recommendations.

Risk level: high.

Requires stronger governance.

Phase 4 — Merchant-Facing Insights

Expose carefully controlled explanations to merchants.

Use cases:

approval-rate insights,
decline reason summaries,
payment method recommendations,
device health dashboard,
settlement anomaly explanation.

Risk level: high.

Requires product, legal, compliance, and security review.

Phase 5 — Agentic Payment Operations

Allow AI agents to propose actions across systems, but with approval gates.

Use cases:

create support ticket,
recommend routing experiment,
generate incident summary,
prepare merchant communication,
suggest fraud rule review.

Risk level: very high.

Execution must remain controlled.

⸻

Strategic Position

The future of AI in payments is not a chatbot sitting next to the payment system. It is a grounded intelligence layer across the payment lifecycle.

The best architecture is not:

LLM replaces the payment engine.

It is:

certified payment systems execute; RAG-grounded AI explains, investigates, assists, and optimizes.

This is exactly where the ENWAR principle becomes relevant outside wireless networks. The value is not merely in generating text. The value is in converting complex, multi-source system signals into situational awareness.

For POS, SoftPOS, and e-commerce platforms, that means:

fewer unexplained declines,
faster support resolution,
better fraud review,
more transparent risk decisions,
better merchant experience,
stronger operational intelligence,
safer use of AI in regulated payment environments.

⸻

Conclusion

LLMs are powerful, but they are not naturally trustworthy payment experts. They need grounding.

RAG gives payment AI the missing layer: access to fresh, domain-specific, evidence-based context. Multi-modal RAG extends this further by allowing the system to reason across many forms of payment telemetry: transaction events, device signals, fraud outputs, merchant configuration, support history, and compliance documentation.

The most promising application of LLMs in payments is not autonomous transaction approval. It is payment situational awareness.

A RAG-empowered payment intelligence layer can help answer the questions that matter most:

What happened?
Why did it happen?
What evidence supports that conclusion?
What should we do next?
What remains uncertain?
Can this explanation be audited?

That is where AI can create real value in POS and e-commerce payments: not by replacing the payment architecture, but by making it more understandable, explainable, and operationally intelligent.

⸻

Proposed Title Options

Payment Intelligence with RAG: Applying Environment-Aware AI Principles to POS and E-Commerce
From Wireless Awareness to Payment Awareness: A RAG-Based Architecture for AI in Payments
Grounded AI for POS and E-Commerce: Using RAG to Make Payment Systems Explainable
Beyond Chatbots: RAG-Empowered LLMs for Payment Operations and SoftPOS Intelligence
Payment Situational Awareness: A Practical Architecture for LLMs, RAG, POS, and E-Commerce

⸻

Recommended Core Message

The winning approach is not to put an LLM inside the authorization path and ask it to decide. The winning approach is to build a payment-aware RAG layer around the transaction lifecycle, allowing AI to explain, investigate, and recommend based on real operational evidence.